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SECTION  I 


INTRODUCTION 

For  the  past  several  years  ESD  has  been  Involved  in  various 
projects  relating  to  secure  computer  systems  design  and  operation. 

One  of  the  continuing  efforts,  started  In  1972  at  NITRE,  has  been 
secure  computer  system  modeling.  The  effort  Initially  produced  a 
mathematical  framework  and  a model  [1,  2]  and  subsequently  developed 
refinements  and  extensions  to  the  model  [3]  which  reflected  a 
computer  system  architecture  similar  to  that  of  Hultlcs  [4].  Recently 
a large  effort  has  been  proceeding  to  produce  design  for  a secure 
Multlcs  based  on  the  mathematical  mode'  given  In  [1,  2,  3]. 

Any  attempt  to  use  the  model,  whose  documentation  existed  In 
three  separate  reports  until  this  document  was  produced,  would  have 
been  hampered  by  the  lack  of  a single,  consistent  reference.  Another 
problem  for  designers  Is  the  difficulty  of  relating  the  abstract 
entitles  of  the  model  to  the  real  entitles  of  the  Multlcs  system. 

These  two  problems  are  solved  by  this  document. 

All  significant  material  to  date  on  the  mathematical  model  has 
bev.*n  collected  In  one  place  In  thr  Appendix  of  this  report.  A 
number  of  minor  changes  have  been  Incorporated,  most  of  them 
notational  or  stylistic.  In  order  to  provide  a uniform,  consistent, 
and  easy- to- read  reference.  A substantive  difference  between  the 
model  of  the  Appendix  and  that  of  the  references  [2,  3]  is  the  set 
of  rules:  the  specific  rules  presented  in  Appendix  have  been  adapted 
to  the  evolving  Multlcs  security  kernel  design. 
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Because  the  model  Is  by  nature  abstract  and,  therefore,  not 
understandable  iri  one  easy  reading.  Section  II  gives  a prose 
description  of  the  model. 

In  order  to  relate  the  mathematical  model  to  the  Multlcs 
design.  Section  III  exhibits  correspondences  from  Multlcs  and 
security  kernel  entitles  to  model  entities. 

Section  IV  discusses  further  cor.s1derations--top1cs  which  lie 
outside  the  scope  of  the  current  model  but  which  are  important  Issues 
for  security  kernel  design. 

As  background  for  the  remainder  of  this  document,  we  briefly 
establish  a general  framework  of  related  efforts  in  the  rest  of  this 
section. 

Work  on  secure  computer  systems,  in  one  aspect  or  another,  has 
been  reported  fairly  continuously  since  the  mid  1960s.  Three  periods 
are  di  cemlble:  early  history,  transitional  history,  and  current 
events. 

The  work  by  Weissmann  [5]  on  the  ADEPT-50  system  stands  out  In 
the  early  history  period.  Not  only  was  a fairly  formal  structuring 
of  solution  to  a security  problem  provided,  but  ADEPT-50  was  actually 
built  and  operated.  In  this  '’arly  pe  iod  the  work  of  Lampson  [6] 

Is  mcst  representatl ve  c*  attempts  to  attack  security  problems 
rigorously  through  a formal  medium  of  expression.  In  Lampson's 
work,  the  problem  of  access  control  is  formulated  very  abstractly 
for  the  first  time,  using  the  concepts  of  "subjects,"  "object,"  and 
"access  matrix."  The  early  period,  which  ended  in  1972,  understandably 
did  not  provide  a complete  and  demonstrable  mathematical  formulation 
of  a solution. 
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The  transitional  period  (1972  - 1974)  Is  character! zed  by 
markedly  Increased  Interest  In  computer  security  issues  as 
evidenced  I-  > the  Anderson  panel  [7].  One  of  the  principal  results 
of  this  oanei  was  the  characterization  of  a soluiiu..  the  problem 
of  secure  computinq  (using  the  concent  of  a "reference  monitor") 
together  with  the  reasoned  dictum  that  comprehensive  and  rigorous 
modeling  Is  Intrinsic  to  a solution  to  the  problem.  This  period  also 
saw  the  development  of  the  first  demonstrated  mathematical  models 
[1,  2,  13]  as  well  as  ancillary  mathematical  results  which  characterized 
the  nature  of  the  correctness  proof  demonstration  [2,  P].  A second 
modeling  effort,  also  sponsored  by  the  Electronic  Systems  Division 
of  *he  United  States  Air  Force  and  performed  at  Case-Western 
Reserve  University,  was  also  undertaken  in  this  period  [9].  In 
this  model,  the  flow  of  information  between  repositories  was 
investigated,  ioUially  in  a static  environment  (that  is,  one  in 
which  neither  creation  nor  deletion  of  agents  or  repositories  is 
allowed)  and  subsequently  in  a dynamic  environment.  *‘any  other 
papers  appeared  during  this  period.  An  implementation  of  a system 
based  .>n  a mathematical  model  was  carried  out  at  MITRE  by 
W.  L.  Schiller  [10].  An  extension  and  refinement  of  the  first 
model  was  developed  [3]  to  tailor  the  model  to  the  exigencies  of 
a proposed  Multics  Implementation  of  the  model;  included  in  this 
extension  was  a concept  promulgated  at  Case-Western  Reserve 
concerning  compatibl 1 1 ty  between  the  Multics  directory  structure 
and  the  classifications  of  the  individual  files.  A great  number  of 
other  computer  security  Issues  were  investigated  and  characterized 
[11,  12,  13,  14,  15]  during  this  time. 

Current  work  succeeding  the  work  reported  above  is  a project 
sponsored  by  ESD  and  ARPA.  In  this  project,  the  Air  rorce,  the 
MITRE  Corporation,  and  Honeywell  are  working  cc.  perati vely 
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to  develop  « design  for  a security  kernel  for  the  Honeywell  Nultlcs 
(Hli.  level  68)  computer  system.  Other  significant  effort"  include  work 
at  UCLA  [16],  and  the  Stanford  Research  Institute  [17]. 

This  report  summarizes,  both  narratively  and  fo«mally,  the 
particular  version  of  the  mathematical  model  that  is  relevant  to 
the  development  of  a Multics  security  kernel.  The  report  not 
only  presents  the  model  In  convenient  and  readable  form,  but  a"so 
explicitly  relates  the  model  to  the  emerainq  Multlcs  kernel  desiqn 
to  help  bridge  the  gap  between  the  mathematical  notions  of  the  model 
and  their  counterparts  in  the  Multics  security  kernel. 
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SECTION  II 


DESCRIPTION  OF  THE  MODEL 

The  model  can  be  viewed  as  having  three  major  facets--a 
descriptive  capability  (the  elements),  general  mechanisms  (the 
limiting  theorems),  and  specific  solutions  (the  rules).  In  this 
section,  we  shall  discuss  these  three  facets  narratively,  make 
explicit  the  inclusions  and  exclusions  of  meaning  (that  is, 
interpretations)  that  can  be  correctly  associated  with  the  model 
Itself  rather  tnan  with  its  interpretation  in  any  given  context. 

A summary  of  the  model  is  Included  in  the  Appendix;  however 
reference  to  the  Appendix  should  not  oe  necessary  for  complete 
understanding  of  this  section. 

DESCRIPTIVE  CAPABILITY 

The  modes  has  the  ability  to  represent  abstractly  the  elements 
of  computer  systems  and  of  security  that  are  relevant  to  a treatment 
of  classified  information  stored  in  a computer  system.  'The  essential 
problem  is  to  control  access  of  active  entities  to  a set  of  passive 
(that  is,  protected)  entities,  based  on  some  security  policy.  Active 
entities  are  called  subjects  (denoted  individually  and  5 
collectively);  passive  entities  are  called  objects  (denoted  0-  and 
l1) . No  restriction  is  made  regarding  entities  that  may  be  both 
subjects  and  objects:  a given  interpretation  of  the  model  could  have 
no  subject/objects,  some  subject/objects,  or  all  subjects  could  be 
objects.  It  Is  meiely  required  that,  when  an  entity's  active 
( *-especti vely,  passive)  role  Is  being  considered,  that  entity  be 
constrained  by  the  me  lei's  treatment  of  subjects  (respectively, 
objects). 

+Nott  that  the  model  is  in  no  way  restricted  to  a computer  system 
(although  that  is  the  topic  here).  It  has  also  been  applied  to 
physical  and  procedural  security  controls. 
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As  in  computer  systems,  access  in  the  model  can  assume 
different  modes.  The  modes  of  access  in  the  model  are  called 
access  attributes  (denoted  x and  A).  The  access  attributes  are 
abstracted  from  actual  access  modes  in  computer  systems. 

The  two  effects  that  an  access  can  have  on  an  object  are  the 
extraction  of  information  ("observing"  the  object)  and  the 
insertion  of  information  ("altering"  the  object).  There  are  thus 
four  general  types  of  access  imaginable: 

• no  observation  and  no  alteration; 

• observation,  but  no  alteration; 

• alteration,  but  no  observation;  and 

• both  observation  and  alteration. 

An  access  at'H'bute  for  each  of  these  possibilities  is  included  in 
the  model : 
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• e access  (neither  observation  nor  alteration); 

• jr  access  (observation  with  no  alteration); 

• a access  (alteration  with  no  observation);  and 

• w access  (both  observation  and  alteration). 

The  symbols  e,  r,  a,  and  w are  derived  from  the  generalized 
access  modes  execute,  read,  append,  and  write,  and  in  fact,  the 
underlined  words  are  used  interchangeably  with  the  shorter  letter 
symbols.  The  meaning  of  any  access  attribute,  however,  is  not  at 
all  constrained  by  an  actual  access  mode  with  the  same  name.  + Rather 
each  actual  access  mode  must  be  analyzed  and  paired  with  the  access 


attribute  which  matches  its  own  access  characteristics.  The  only 
intrinsic  semantics  that  pertain  to  every  interpretation  of  the 
model  access  attributes  are  those  listed  in  the  preceding  paragraph. 

It  is  now  possible  to  begin  a description  of  a system  state  in 
the  model.  The  state  will  be  expressed  as  a set  of  four  values,  each 
referred  to  as  a component. 

The  first  component  of  a system  state  is  the  current  access  set, 
denoted  b.  A current  access  by  a subject  to  an  object  is  represented 
by  a triple: 

(subject,  object,  access-attribute) . 

This  triple  means  that  "subject"  has  current  'access-attribute" 
access  to  "object"  in  the  state.  The  current  access  set  b is  a 
set  of  such  triples  representing  all  current  accesses. 

The  next  element  of  a system  state  within  the  model  concerns  a 
structure  imposed  on  the  uojects.  What  we  stipulate  is  that  a 


'Note  that  this  abstract  notion  o f "execute"  access  is  not  what  is 
typically  implemented  (enforced)  by  computer  hardware  since  the 
results  of  the  execution  reflect  the  contents  and  thus  constitute 
"observation"  of  the  executed  element. 


;;arent-child  relation  be  maintained  which  allows  only  directed, 
rooted  trees  and  isolated  points  as  shown: 


Figure  2.  The  Desired  Object  Structure 

This  particular  structure  is  desired  in  order  to  take  advantage  of 
the  implicit  control  conventions  of  and  the  wealth  of  experience 
with  logical  data  objects  structured  in  this  way.  The  construct  used 
is  called  a hierarchy  (denoted  H and  H);  a hierarchy  specifies  the 
progeny  of  each  object  so  that  structures  of  the  type  mentioned  are 
the  only  possibilities. 

The  next  state  component  which  we  consider  involves  access 

permission.  Access  permission  is  included  in  the  model  in  an  access 
. i* 

matrix  f'. 


^Notice  that  11  is  a matrix  only  in  the  model's  conceptual 
sphere:  any  interpretation  of  M which  records  all  the  necessary 

information  is  acceptable. 
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The  component  records  the  modes  in  which  subject  T ^ is 

permitted  to  access  object  Oj.  Thus  the  entries  of  M are  subsets 
of  the  set  A of  access  attributes. 

The  last  component  of  a system  state  is  a level  function,  the 
embodiment  of  security  classifications  in  the  model.  In  a 
military  or  governmental  environment,  people  and  documents  can 
receive  two  types  of  formal  security  designations:  one  is 

classification  or  clearance  (unclassified,  confidential,  secret, 
and  top  secret  are  usual)  and  the  other  is  formal  category  (such  as 
Nuclear,  NATO,  and  Cryptd.  A total  security  designation  is  a pair: 

(classification,  set  of  categories). 

Such  a pair  we  call  a "security  level.”  A necessary  condition  for 
an  individual's  possession  of  a document  is  that  his  security  level 
must  dominate  the  security  level  of  the  document.  One  level 
dominates  another: 
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(class  1,  category-set  1)  dominates  (’•.lass  2,  category-set  2) 

*f  and  only  if 

class  1 is  greater  than  or  equal  to  class  2 and 
category-set  1 includes  catego-y-set  2 as  a subset. 

This  rather  complicated  requirement  is  abbreviated  in  this  discussion 
by  using  abstract  security  levels  (denoted  l and  L)  and  a dominance 
ordering  » (read  "dominates")  which  is  required  to  be  a partial 
ordering. + 

The  c ossification  of  subjects  and  objects  assigns  to  each  subject 
and  to  each  object  a security  level.  The  (maximum)  security  level  of 
a subject  is  denoted  "^(S^)"  in  the  formal  development  in  the 
Appendix,  but  for  the  purposes  of  this  section  will  be  denoted 
"level(S^)."  Similarly,  the  security  level  of  an  object  Oj  is 
denoted  formally  end  informally  as  fg(Oj)  an<*  ^eve^0j).  One 
further  assignment  to  subjects  identifies  the  current  security 
level  of  the  subject.  The  current  level  allows  a subject  to  operate 
at  less  than  its  maximum  security  level,  a feature  that  is  very 
important  under  some  of  the  security  constraints  to  be  developed 

+ -j. 

later.  The  current  security  level  of  a subject  S..  is  denoted 
^(S^)  and  current-level^);  it  is  required  that  level(S^)  dominate 
current- level (S.. ). 

+ 

That  the  relation  » must  be  a partial  ordering  requires  only  that 
1)  Lu  dominates  l_u  for  every  level  Lu;  2)  Lu  dominates  Ly  and 
L dominates  L.  then  L dominates  L ; and  3)  <f  L and  L 

V w u w U “ 

dominate  each  other,  then  they  are  the  same. 

4*  4- 

In  particular,  the  current  security  level  makes  feasible  the 
requirement  that  high-level  information  not  be  put  into  low-level  objects. 
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A triple  of  security  level  assignment  functions  (fs,  f0,  f^.)  or 
( level ( • ) » leve1(*)»  cur-ent-1evel(*5)  is  called  a level  function 
and  Is  denoted  f(or,  collectively,  F). 

A state  of  the  model  is  a 4- tuple  of  the  form: 

(current  access  set,  access  permission  matrix,  level 

function,  hierarchy). 

The  model  notation  for  a state  Is  (b,  M,  f,  H). 

We  refer  to  inputs  to  the  system  as  requests  (F^  and  R)  and 
outputs  as  decisions  (Dm  and  D).  The  system  is  all  sequences  of 
(request,  decision,  state)  triples  with  some  initial  state  (zQ) 
which  satisfy  a relation  W on  successive  states. 

The  system  defined  in  this  way  can  be  used  in  two  ways--analysis 
and  synthesis.  The  use  of  the  model  for  analysis  Involves: 

1.  the  specification  of  R and  D for  the  system 
being  analyzed,  and 

2.  the  determination  of  W. 


The  operation  of  the  system  of  concern  can  then  be  addressed  by 
examining  the  relation  W which  characterizes  the  system  as  a 
model.  The  use  made  of  the  model  In  the  security  kernel  design 
work  is  synthesis:  the  job  Involves  first  the  specification  of 
system  characteristics  that  we  desire  to  be  maintained,  and  then 
the  definition  of  a relation  W that  is  sufficient  to  the  task. 
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of  the  system  characteristics  that  we  desire  to  be  maintained. 

These  characteristics  we  speak  of  "ollectlvely  as  "security." 

The  first  aspect  of  security  which  we  consider  is  the  simple 
security  property  (ss-property  hereafter).  The  ss-property  Is 
satisfied  if  every  "observe"  access  triple  (subject,  object,  attri- 
bute) in  the  current  access  set  b has  the  property  that  level  (subject) 
dominates  level  (object).  More  concisely,  the  ss-property  stipulates 
that  if  (subject,  objec  , observe-attribute)  is  a current  access, 
then  level  (subject)  dominates  level  (object). 

The  ss-property  is  the  strict  interpretation  of  the  current 
security  regulations  for  documents,  with  one  modification.  In  a 
document  system,  "access"  refers  to  physical  possession  which 
implies  the  ability  to  extract  information.  Where  there  is  the 
possibility  of  access  without  observation,  as  in  this  model,  access 
does  not  necessarily  imply  the  ability  to  extract  information. 

Hence,  the  security  regulati 'ns  for  documents  were  applied  in  the 
model  only  to  attributes  that  entail  observation  (viz.  w and  r). 

The  ss-property  was  considered  to  be  the  whole  of  security  in 
our  early  efforts  at  modeling  [1].  A brief  look  at  the  expected 
interpretation  of  the  moael  will  show  that  this  property  is  indeed 
only  a "simple"  statement  of  the  problem. 

The  expected  interpretation  of  the  model  anticipates 
protection  of  information  containers  rather  than  of  the  information 
itself.  Hence  a malicious  program  (an  interpretation  of  a subject) 
might  pass  classified  information  along  by  putting  it  into  an 
information  container  labeled  at  a lower  level  than  the  information 
itself. 


Jfc  1 high  level  object-1 


Figure  4:  Information  Flow  Showing  the  Need  for  *-Property 

Thus,  another  security  property,  called  the  *-property*  (for  historical 
reasons).  Is  added  to  the  ss-property  in  the  specification  of 
"security."  The  *-property  Is  satisfied  if: 

in  any  state,  if  a subject  has 

simultaneous  "observe"  access  to  object-1  and  "alter" 
access  to  object-2,  then  level  (object-1)  is  dominated 
by  level  (object-2). 

This  definition  clearly  disallow?  the  situation  pictured  (Figure  4). 
Under  this  restriction,  however,  the  levels  of  all  objects  accessed 
by  a given  subject  are  neatly  ordered: 

level  (a^accessed-object)  dominates  level  (w-accessed-object); 
level  (w-accessed-object-1 ) equals  level  (w  accessed-object-2) ; and 
level  (w-accessed-object)  dominates  level  (r-accessed-object). 

+read  "star-property." 
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Thus  the  definition  of  ^-property  Is  now  refined  In  terms  of 
current-level  (subject): 

in  any  state,  a current  access  (subject,  object,  attribute) 

Implies: 

level  (object)  dominates  current-level  (subject)  if 
attribute  Is  a; 

level  (object)  equals  current-level  (subject)  If 
attribute  Is  w;  and 

level  (object)  Is  dominated  by  current-level  (object) 

If  attribute  is  r. 

There  are  two  Important  comments  to  be  made  about  the  ^-property. 

First,  it  does  not  apply  to  trusted  subjects:  a trusted  subject  Is 
one  guaranteed  not  to  consummate  a securlty-breacninq  information 
transfer  even  If  it  is  possible. + Second,  it  is  Important  to 
remember  that  both  ss-property  and  *~property  are  to  be  enforced. 
Neither  property  by  itself  ensures  the  "security"  we  desire. 

There  is  one  further  aspect  of  security  that  we  address:  the 

problem  is  called  discretionary  security  and  It  is  also  based  on 
current  military/governmental  policy  (known  as  "need-to-know").  The 
enforcement  of  classification/clearance  matching  Is  mandated  by  executi 
order,  directive  and  regulation:  an  individual  may  not  exercise  his 

own  judgment  to  violate  this  standam.  Similarly,  the  enforcement  of 
categories  (also  called  formal  need-to-know  compartments)  is  mandatory. 
These  two  restrictions  make  up  nondiscretionary  security  policy  and  are 


+The  topic  of  trusted  subjects  is  treated  at  more  length  in 
Section  IV. 
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wnbotiftd  In  the  model  as  the  ss-property  and  ‘-property.  Discretionary 
security  policy  allows  an  Individual  to  extend  to  another  Individual 
access  to  a document  based  on  his  own  discretion,  constrained  by  non- 
dlscretlonary  security  policy:  that  Is,  discretionary  security  policy 

allows  an  Individual  to  extend  access  to  a document  to  anyone  that  Is 
allowed  by  non-dlscretlonary  security  to  view  the  document. 

This  exact  property  Is  Included  In  the  model  In  the  discretionary 
security  property  (ds-property).  A state  satisfies  the  ds -property 
provided  every  current  access  Is  permitted  by  the  current  access 
permission  matrix  M.  More  specifically,  the  ds-property,  requires 
that: 


If  (subject-1,  object-j,  attrlbute-x)  is  a current  access 
(is  In  b),  then  attrlbute-x  Is  recorded  In  the 
(subject-1,  object-j)  - component  of  M (ils  V- 

The  term  "dlscretlonan/"  security  Is  appropriate  In  the  context  of 
the  specific  solutions  of  this  rodel  since  the  capaolHty  to  alter 
H (the  permission  structure)  is  included  in  the  model. 

Note  that  re^trictio.  s of  the  concept  of  security  will  not 
require  reproof  of  the  properties  already  established  because 
additional  restrictions  can  only  reduce  the  set  of  reachable  states. 
The  notion  of  "security"  v«:  purposefully  made  extensible  in  this 
way  to  allow  for  later  refinements  of  the  concept  of  security/ 

GENERAL  MECHANISMS 

This  discussion  of  the  general  mechanisms  of  the  model  Is 
tripartite.  First,  the  "Inductive  nature"  of  security  within  the 

^Some  discussion  of  other  security-related  topics  which  might  be 
Included  in  later  definitions  of  security  is  given  in  Section  IV. 


19 


model  Is  established.  Then  a general  construct— the  rule— for  the 
modular  specification  of  system  capabilities  Is  defined.  Finally, 
the  relation  of  rule  properties  to  system  properties  Is  established. 

The  first  general  result  In  the  model  Is  the  basic  security 
theorem  (Corollary  A1  In  the  Appendix).  This  theorem  states  that 
security  (as  defined)  can  be  guaranteed  systemlcally  when  each 
alteration  to  the  current  state  does  not  Itself  cause  a breach  of 
security.  Thus  security  can  be  guaranteed  systemlcally  If,  whenever 
(subject,  object,  attribute)  is  added  to  the  current  access  set  b, 
then: 

1.  level (subject)  dominates  level (object)  If 

attribute  involves  observation  (to  assure  the 
ss-property); 

2.  current-level (subject)  and  level (object)  have 

an  appropriate  dominance  relation  (to  assure  the 
♦-property);  and 

3.  attribute  is  contained  in  the  (subject,  object) 

component  of  the  access  permission  matrix  f 
(to  assure  the  ds-property). 

We  say  that  the  basic  security  theorem  establishes  the  "Inductive 
nature"  of  security  in  that  it  shows  that  the  preservation  of 
security  from  one  state  to  the  next  guarantees  total  system 
security. 

The  Importance  of  this  result  should  not  be  underestimated. 
Other  problems  of  seemingly  comparable  difficulty  are  not  of  an 
Inductive  nature.  The  problems  of  data-  and  resource-sharing,  for 
example,  are  not  inductive.  In  fact,  the  most  trivial  example  of 
deadlock  (Figure  5)  can  arise  in  any  nontrivial  sharing  system  that 
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Figure  5.  Deadlock 


decides  limed lately  to  grant  or  deny  a request  for  access. 

Resolution  of  this  problem  requires  knowledge  of  future  possibilities, 
queues  of  requests,  and  process  priorities  [18].  The  result, 
therefore,  that  security  (as  defined  In  the  moCel ) is  inductive 
establishes  the  relative  simplicity  of  maintaining  security:  the 
minimum  check  that  the  proposed  new  state  is  "secure"  is  both 
necessary  and  sufficient  for  full  maintenance  of  security. 

The  second  step  of  constructing  general  mechanisms  within  the 
model  Is  a direct  consequence  of  the  basic  security  theorem.  Since 
the  systemic  problems  of  security  can  be  dealt  with  one  state 
transition  at  a time,  a general  framework  for  isolating  single 
transitions  was  devised.  This  framework  relies  on  the  "rule,"  a 
function  for  specifying  a decision  (an  output)  and  a next-state  for 
every  state  and  every  request  (an  Input): 

(request,  current-state) >(decision,  next-state). 
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The  1d»a  Is  to  analyze  each  class  of  requests  separately  In  a rule 
designed  to  handle  that  i irtlcular  class.  To  provide  clarity,  no 
two  rules  (In  a given  system)  are  allowed  to  specify  non-trlvlal 
changes  for  a given  (request,  current-state)  pair;  total  system 
"response"  to  the  pair  (request,  current-state)  Is  then  defined  as 
the  response  of  the  rule  written  to  handle  the  request.  This  frame- 
work allows  different  approaches  to  a given  class  of  requests  to  be 
worked  out  Independently  in  different  rules.  A final  set  of  rules 
to  specify  a desired  system  could  be  chosen  to  reflect  idiosyncratic 
needs;  the  only  restriction  Is  that  rules  with  overlapping 
responsibility  cannot  be  used  together.  This  approach  gives  the 
model  a modular  flexibility  which  c<n  be  of  great  use  in  tailoring 
the  model  to  a particular  application,  as  Illustrated  by  Section  III. 

The  last  development  which  Is  classed  a general  development 
centers  on  the  relation  of  rule  properties  to  system  properties.  It 
has  been  shown  that  the  entire  system  specified  by  a set  of  rules 
satisfies  all  three  security  properties--the  ss-property,  the 
•-property,  and  the  ds-property- -prov  ded  each  rule  itself 
introduces  no  exception  to  these  properties.  Moreover,  the 
requisite  demonstration  that  a rule  preserves  security  can  in  most 
cases  be  reduced  to  the  direct  consideration  of  the  small  number 
of  state  alterations  involved  in  the  given  state  transition  (Corollary 
A3  In  the  Appendix). 

In  summary,  the  general  mechanisms  of  the  model: 

• bound  the  scope  of  investigation  to  single  transitions  of  state; 

• provide  the  ability  to  Investigate  desired  features  of  the 
system  Independently  of  one  another  using  the  rule  framework; 
and 
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• reduce  the  systemic  problem  to  very  restricted  rule-based 
problems  of  the  preservation  of  security  properties  over 
one  transition. 

SPECIFIC  SOLUTIONS 

The  rules  presented  in  this  docunent  represent  one  specific 
solution  to  the  requirement  for  a "secure"  computer  system  This 
particular  solution  Is  in  no  sense  unique,  but  ..as  been  specifically 
tailored  for  use  with  a Mu1 tics-based  information  system  design.  For 
this  use,  the  solution  has  to  satisfy  two  requi rements : the 
provision  of  generally  useful  functions  and  appropriate  accomodations 
to  the  effects  of  the  Multics  design  on  an  implementation  of  this 
model . 

A number  of  general  functions  can  be  suggested  for  any  computer- 
based  information  system.  With  reference  to  the  model  described 
earlier,  the  functions  can  be  grouped  in  four  classes: 

• functions  to  alter  current  access  (the  set  b); 

• functions  to  alter  the  level  functions  (the  values 

level (subject),  level (object),  and  current-level (subject) ) ; 

• functions  to  alter  the  current  access  permission  structure 
(the  matrix  M);  and 

• functions  to  alter  the  object  structure  (the  hierarchy  H). 

This  list  covers  changes  to  each  of  the  elements  of  a system  state 
In  the  model.  Our  particular  solution  Includes  the  capability  to 
cause  the  following  changes  to  the  system  state: 
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• altering  current  access: 

• to  get  access  (add  a triple  (subject,  object, 
attribute)  to  the  current  access  set  b),  and 

• to  release  access  (to  remove  an  access  triple  from 
the  current  access  set  b); 

• altering  level  functions: 

• to  change  object  level  (to  change  the  value  of 
level (object)  for  some  object),  and 

• to  change  current  level  (to  change  the  value  of 
current-level (subject)) ; 

• altering  access  permission: 

• to  give  access  permission  (to  £,dd  an  attribute  to 
some  component  of  the  access  permission  matrix  M), 
and 

• to  rescind  access  permission  (to  delete  an  attribute 
from  some  component  of  the  access  permission  matrix 
M);  and 

" altering  the  hierarchy: 

• to  create  an  object  (to  attach  an  object  to  the 
current  tree  structure  as  a leaf),  and 

• to  delete  a group  of  objects  (to  detach  from  the 
hierarchy  an  object  and  all  other  objects  "beneath" 
it  in  the  hierarchy). 

Section  III  presents  a more  detailed  discussion  of  the  particular 
rules  presented  in  this  document. 

These  rules  reflect  several  characteristics  of  the  Multics 
operating  system.  The  main  Multics  characteristic  that  affects  the 
model  is  the  hierarchical  object  structure  which  has  been  mentioned 
previously.  The  principal  reason  for  the  inclusion  of  the 


hierarchy  In  the  model  is  the  desire  to  disturb  the  Multics  operating 
system  as  little  as  possible  while  adding  the  capability  to  process 
simultaneously  information  of  varying  security  levels.  The  basic 
Multics  mechanisms  for  access  control  rely  heavily  on  the  object 
structure:  to  retain  that  basic  structure  it  is  necessary  to 
investigate  our  restrictions  on  access  control  in  the  Multics  sottinq 
of  an  object  hierarchy--that  is,  in  the  setting  of  Multics  control 
structures. 

The  second  Multics  characteristic  involves  the  physical 
counterpart  of  the  access  permission  matrix  M.  This  structure  (called 
the  Access  Control  List  (ACL)  in  Multics),  its  location,  and  its 
manipulation  have  direct  effects  on  the  capability  to  get  access,  to 

i 

give  access,  and  to  rescind  access  in  Multics.  The  Access 
Control  List  in  Multics  is  a list  of  "(process,  ring  bracket)"  pairs ^ 
(for  our  purposes  here,  the  Multics  analogue  of  subjects)  allowed  to 
access  a segment  (that  is,  an  object)  and  the  modes  of  access  allowed. 
There  is  one  Access  Control  List  for  every  segment/object.  Thus  the 
information  contained  in  the  Access  Control  List  for  object-j  includes 
the  information  contained  in  the  j-th  column  of  the  access  permission 
matrix  M in  the  model.  The  most  important  fact  about  the  Multics 
ACLs  is  that  they  are  contained  in  a segment's  parent  directory  (parent 
object  in  the  model)  and  are  manipulated  by  manipulation  of  the  object's 
parent.  Hence,  "control"  over  an  object  (to  extend  access,  to  rescind 
access,  or  to  destroy  the  object  althogether)  is  equivalent  in  Multics 
to  write  permission  to  the  object's  parent.  Moreover,  since  "creation" 
of  a segment  in  Multics  is  the  insertion  of  a new  entry  (called  a 
"branch")  in  a directory  segment,  the  "control"  over  creation  is 
equivalent  to  write  or  append  access  (that  is,  read/write  or  pure-write 
access)  to  the  directory  segment  that  will  be  the  parent  of  the  created 
segment  (directory  Z in  Figure  7). 

^The  entry  into  the  ACL  by  process  is  actually  indirect:  a process 

maps  to  a "user-id"  (essentially  a set  of  processes  associated  with 
a particular  user)  which  in  turn  maps  to  an  ACL  entry.  To  simplify 
the  exposition  here,  this  indirect  entry  is  represented  directly. 
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Figure  7.  The  "Creation"  of  a . ent  in  Multics  ] 

These  Multics  characteristics  are  taken  into  account  in  the  1 

model's  rule  where,  for  example,  a request  to  give  access  to  an  object  j 

is  allowed  only  if  (among  other  things)  the  requesting  subject  has 
current  w access  to  the  parent  of  the  object  (implying  that  the  usual 

Multics  operation  of  extending  access  can  be  carried  out).  j 
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Figure  8.  The  Need  for  Compatibility 


The  way  access  to  an  object  Is  carried  out  in  titles  is  the 
final  characteristic  reflected  in  the  model.  A user  request  to 
access  a segment  causes  the  user's  surrogate  (his  process)  to  access 
every  object  In  the  hierarchy  in  the  path  from  the  root  directory 
(the  object  Op  in  the  model)  to  the  segment  of  interest.  This 
fact  implies  that  in  the  situation  shown  in  Fiqure  8,  an  unclassified 
subject  would  have  to  observe  the  secret  object  0^  in  order  to 
access  the  unclassified  object  02:  an  unclassified  subject  cannot 
observe  the  secret  object  0^  because  of  the  ss-property.  Moreover, 
the  *-property  combined  with  the  requirement  to  "write"  in  0(  in 
order  to  "create"  object  02  make  any  situation  similar  to  that  in 
Figure  8 useless.  Hence,  it  is  required  in  the  rules  of  the  model 
that  the  security  level  of  an  object  dominate  the  security  level  of 
it?,  parent. + The  rules  to  allow  creation  of  objects  and  to  cause 
changes  in  an  object's  security  level  reflect  this  requirement,  which 
is  termed  "compatibility.'^' 

The  rules  of  this  document  provide  a particular  specification 
for  a secure  computer  system  that  supplies  a full  complement  of 
information  processing  capabilities  while  matching  the  special 
requirements  of  the  Mu  I tics  operating  system  environment. 


+ Remember  that  if  the  two  levels  are  the  ..ame,  this  requirement  is  met. 

++The  concept  termed  "compatibility"  here  was  initially  proposed  and 
investigated  at  Case  Western  Reserve  University  [9]. 
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SECTION  III 

MORPHISM  FROM  MULTICS  TO  MODEL 

introduct;on 

The  discussion  of  the  correspondence  of  the  Multics  security 
kernel  design  to  the  mathematical  model*  will  be  phrased  In  terms 
of  a "morphism;"  this  stance  is  taken  because  of  tho  verification 
strategy  that  has  been  proposed  for  the  Multics  kernel  design  [19]. 

A morphism  is  a mapping  from  one  system  to  another  which 
preserves  one  or  more  operations  of  the  system.  This  concept  can 
be  stated  mathematically  in  concise  form.  Exposition  of  the 
concept  is  better  achieved  by  example.  Suppose  [I,  +,  •]  is  the 
following  algebraic  system: 

I is  the  set  of  integers  from  0 to  9. 

+ is  the  ordinary  arithmetic  sum  operator  except  addition  is 
to  be  done  modulo  10;  that  is,  ordinary  sum  equal  to 
10  becomes  0,  li  becomes  1,  12  becomes  2,  and  so 
forth. 

• is  the  ordinary  arithmetic  product  operator  except 
multiplication  is  to  be  done  modulo  10. 

Suppose  [A,  ©]  is  the  following  algebraic  system: 

A is  the  set  of  letters  a,  b,  c,  d,  e. 

® is  a binary  operator  defined  as  follows: 

*The  term  "model"  refers  specifically  to  the  model  presented  in  the 
Appendix. 
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which  can  be  shown  in  table  form: 
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(•  ' a binary  operator  defined  by: 
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Now  define  the  mapping  M from  the  system  [I,  +,  •]  to  the  system 
[A,  ®,  Ql  as  follows: 
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1 — b 

2 — c 

3 — *■  d 

4 — e 

5 -v  a 

6 b 

7 c 

8 — ► d 

9 — e 

M Is  then  a morphism  from  [I,  + , .]  to  [A.G.G]  since  it  "preserves" 
the  operations  of  + and  •.  This  means  that  the  value  of  the 
expressions  1 + j and  1 - j In  the  system  [I,  +,  .]  have  corresponding 
values  In  [A.G.G]  under  the  mapping  M which  Is  the  same  as  the  value 
obtained  by  (±  ir.g  and  0ng  the  elements  In  [A.  'iXG]  which 
correspond  under  M to  1 and  j In  [I,  + , .].  Symbolically  we 
can  express  this  as  follows: 

M (1  + j ) - M ii)®M  ( j ) and  M ( 1 • j ) = M ( 1 ) 0 M ( j ) . 

By  inspecting  the  previous  definitions  we  can  verify,  for  example, 
that: 


M(1  + 3)  = M( 4)  « e and 
M(1 ) (f  M( 3)  * b (±  b = e so 
M(1  + 3)  3 M(1 ) (+  M(3) , 


Similarly, 
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M(7  • 3)  - M(7)  © M(3)  since 
‘1(7  *3)  ■ M(l)  ■ b and 
M(7)  © M(3)  « c © d = b. 

The  "preservation"  property  of  M can  be  shown  diagrammatically: 


M 


1 

I 


These  diagrams  are  said  to  be  "comnutative."  In  each,  one  can  get 
from  I x I to  A by  two  paths;  each  path  leads  to  the  same 
place,  that  is,  given  two  elements  in  I (an  ordered  pair  In  I * I) 
the  same  element  In  A Is  arrived  at  by  both  paths. 

The  math  model  of  a secure  system  is  like  the  system  [A,  ©,  ©]. 
Corresponding  to  the  set  A is  a set  of  elements  of  the  model.  The 
analogy  Is  most  enlightening  If  we  consider  elements  In  A to 
correspond  to  states  in  the  model.  Corresponding  to  the  operators 
© and  © is  a set  ot  eleven  rules.  The  Multics  system  we  shall 
discuss  Is  like  the  system  [I,  +,  Corresponding  to  the  set  I 
is  a set  of  elements  of  the  system;  again,  consider  the  latter  to  be 
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states  of  the  system.  Corresponding  to  the  'perators  + and  • Is  a 
set  of  algorithms.  Now,  just  as  we  established  a morphism  from 
[I,  + . •]  to  [A,  ©,  ©],  we  wish  to  establish  a morphism  from 
Multics  to  the  model.  In  other  words,  given  a set  of  algorithms 
for  "secure"  operation,  which  correspond  to  rules  of  the  model,  we 
wish  to  establish  a mapping  from  the  elements  of  Multics  to  the 
elements  of  the  model  In  such  a way  that  the  algorithms  (operations) 
are  preserved.  Tor  each  algorithm  we  wish  to  be  able  to  specify  a 
commutative  diagram;  for  example: 

alaorithm  3 


In  this  document  the  mapping  M is  partially  specified.  The  algorithms 
then  are  to  be  so  specified  as  to  be  able  to  show  that  M preserves 
operations;  this  specification  is  outside  the  scope  of  this  report. 

In  the  remainder  of  this  section  we  identify  the  elements  of 
Multics  and  then  show  a preliminary  correspondence  of  the  Identified 
elements  to  the  elements  of  the  model.  It  remains  for  future  effort 
to  show  that  the  correspondence  Is  a morphism. 

ELEMENTS  OF  A SECURE  MULTICS 

State  Elements 


Corresponding  to  a state  (b,  M,  f,  H)  In  the  model  Is  a set 
of  Information  structures  In  Multics.  The  following  correspondences 
hnve  been  identified: 


segment  descriptor  words 

access  control  lists* 

Information  In  directory  segments 
and  special  process  security 
level  tables 

branches 


>M 

^f 

>H+. 


An  element  (S^,  0^,  x)  In  b Indicates  that  subject  has  current 
access  to  object  0^  In  access  mode  x.  In  Multlcs  the  same 
information  is  contained  In  a descriptor  segment  base  register  (DSBR) , 
a temporary  pointer  register  (TPR),  and  a segment  descriptor  word  (SDW) 
An  address  field  In  the  DSBR  Is  a pointer  to  the  head  of  the  descriptor 
segment  for  the  process  (subject)  that  Is  currently  running  on  the 
processor  to  which  the  OSBR  belongs.  The  TP”  gives  an  offset,  in  the 
descriptor  segment,  to  the  SDW  associated  with  the  segment  (object) 
to  which  the  process  has  access.  In  the  SDW  is  a field  which  Indicates 
access  permission  (namely,  read,  execute,  or  write).  When  a process 
is  ready  or  waiting  (not  running)  the  information  in  the  DSBR  and  TPR 
Is  saved  In  the  active  segment  table. 


In  case  the  object  referred  to  In  a triple  of  the  form  (S.,0,,x) 

ft  1 J 

is  something  other  than  a segment,  say  a socket  , correspondences 
like  those  shown  above  must  pertain. 


An  entry  ■ {r,  w}  in  M indicates  that  subject  has 
read  and  write  permission  with  respect  to  object  U..  Suppose  0. 

J J 

Is  a data  segment.  In  Multlcs  this  Information  Is  kept  In  an 
access  control  list.  An  access  control  list  has  the  following  form: 

fThe  Multlcs  described  In  this  report  is  derived  from  Organick's  The 
Multlcs  System  [4].  Multlcs,  as  an  evolving  system,  currently  may  not 
fit  this  description,  but  at  this  writing,  the  variations  were  of  littl 
Importance  to  the  discussion. 

XT 

The  term  "socket"  denotes  a connection  from  a process  to  a physical 
device  for  Input  or  output  operations. 
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user  Identification 


mode  of  accpss 


_r J n g bracket 


G 


3 

i 


user  Identification 


mode  of  access 


ring  bracket 


C 


D 


and  so  forth.1 


Th®  +•  am ^ mm l 1 4 f i / An  N a. ~ — i. l - > * i •«  ^ * 

1 vauiiuui  hSl  Luyutner  wi  lh  otner  mrormation  (e.g., 

physical  location)  makes  up  a branch.  P collection  of  branches  is 

a directory  segment.  Corresponding  to  a . then  we  htve: 

■ J 
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The  security  level  functlo"  f of  the  model  has  the  three 
components: 

f«j:  maximum  security  level  of  subjects; 

f^:  current  operatlnq  security  level  of  subjects; 

f^:  security  level  of  objects. 

For  example,  f^Oj)  ■ confidential  means  that  0j  is  classified 
confidential.  This  Information  would  be  kept  in  a directory 
segment  in  Multics,  perhaps  as  an  extension  of  a branch.  Specific 
Information  structures  for  representing  f^  and  fc  have  not  yet 
been  chosen  at  this  writing;  we  postulate  appropriate  tables 
at  a high  level  of  abstraction  for  establishing  correspondence  to 
the  model. 

The  hierarchy  H of  the  model  Is  structured  to  reflect  the 
tree  structure  among  segments  realized  by  branches  in  Multics; 
correspondence  Is  quite  straightforward.  If  0.  and  0j  are 
objects  In  the  model  and  H(O^)  Includes  0j,  then  0^  is  the 
parent  of  0 j ; the  Multics  structural  eq’iivalent  of  this  situation 
Is  shown  in  Figure  9. 


Figure  9.  Multics  Hierarchy  Equivalent 
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With  respect  to  the  model,  the  Multics  link  is  considered  a 
shorthand  for  a symbolic  pathname:  therefore,  it  introduces  no 
additional  structure. 


ROOT 


Figure  10.  The  Interpretation  of  Links 

From  directory  A in  Figure  10,  the  symbolic  name  "D"  is 

shorthand  for  ">B>D." 

Subjects  and  Objects 

A process-ring  pair  (process,  ring)  in  Multics  corresponds  to  a 
subject  in  the  model.  Corresponding  to  objects  in  the  model  are,  at 
least,  directory  segments,  data  segments,  certain  I/O  devices,  certain 
address  spaces,  and  sockets. 
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Attribute  Elements 


The  set  A =(r.,  e,  w,  aj  is  used  in  the  model  for  access  mode 
designation  with  the  following  meanings: 

r~ read;  observe  only 

e— execute;  neither  observation  nor  alteration 
w--write;  observe  and  alter 
^—append;  alter  only. 

For  data  segments  in  Multics  the  usage  attributes  correspond  as 
f ol 1 ows : 

Multics  Model 

read"- - — > jr 

execute > r , e 

read  and  write w 

write * a_. 

For  directory  segments  the  correspondences  are: 

Multics  Model 

status— >jr 

status  and  modify 

append a_ 

search — > e . 

For  other  objects  in  Multics  the  access  attributes  have  not  yet 
been  specified  sufficiently  to  permit  exact  correspondences  to  be 
established  at  the  time  of  this  writing. 

Corresponding  to  the  set  C = {C-j , Cg.  ....  C^}  of 
classifications  in  the  model  is  a set  of  classifications  in  Multics 
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top  secret 

»C, 

^ r 

f ^ Hanf  4 a 1 _ 

con  t 1 aen ti a i 

> C3 

s.  r 

UIIL  IQOO  1 1 ICU  

Corresponding  to  the  categories  K = (K-j , Kg,  . . . , K^}  of  the 
model  is  a set  of  formal  categories  in  Multics.  The  four 
classifications  above  have  been  adopted  for  general  use  [5];  the 
formal  categories  used  in  any  particular  installation  will  vary. 
For  example,  an  installation  might  establish  the  correspondence: 


NATO 

^ 

i/ 

LKYI  1 u 1 

V 

Kg. 

For  the  present  implementation,  a maximum  of  7 categories  has  been 
adopted  as  the  standard. 

SECURITY  PROPERTIES  IN  A SECURE  MULTICS 

With  the  Multics/model  element  correspondences  as  a foundation, 
the  examination  of  a secure  Multics  can  proceed  with  an  examination 
of  the  properties  of  Multics  which  will  be  deemed  "security" 
properties.  Among  these  properties  are  the  Multics  analogues  of  the 
security  properties  in  the  model;  the  identification  of  other 
security  properties  in  Multics  is  also  included  here. 

The  first  model  property  reflected  in  a secure  Multics  is  the 
ss-property,  or  simple-security  property.  This  property  embodies  the 
military/governmental  policy  on  disclosure,  tailored  tc  a computer 
environment.  In  the  model,  the  ss-property  requires  that  every  current 
access  involving  observation  (an  element  (subject,  object,  observe- 
attribute)  in  the  current  access  set  b)  must  imply  that  the  level  of 
the  subject  dominates  the  level  of  the  object  observed 
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Figure  11.  The  ss-Property  in  Multics 


(level (subject)  » level (object)).  In  Multics,  an  SDW  in  an  active 
segment's  descriptor  segment  with  the  r indicator  on  Indicates  a 
current  observe  for  that  process.  (Recall  that  in  Multics  "read" 

Is  the  only  observe  access  to  data  segments;  "status"  plays  the 
Identical  role  for  directory  segments.)  Thus,  for  an  active  process, 
compliance  with  the  ss-property  means  that  the  r (or  s)  Indicator 
is  on  only  in  those  SLSWs  where  the  level  of  the  process  dominates 
the  level  of  the  segment  described  by  the  SDW  (see  Figure  11).  For 
an  Inactive  process,  compliance  with  the  ss-property  means  that  on 
activation  the  currently  stored  process  information  would  conform  to 
the  requirements  for  an  active  process. 

In  the  model,  the  *-property  places  restrictions  on  current 
access  triples  (subject,  object,  attribute)  based  on  the  value  of 
current-level (subject).  Specifically, 

• if  attribute  is  read,  current-level (subject)  dominates  level (object) ; 

• if  attribute  Is  append,  current-level (subject)  Is  dominated  by 
level (object); 

• if  attribute  is  write,  current-level (subject  ) equals 
level (object) ; and 

• if  attribute  is  execute,  current-level (subject)  and 
level (object)  have  no  required  relation. 

In  Multics,  the  -property  can  be  phrased  for  active  processes,  the 
requirement  for  inactive  processes  being,  as  for  the  ss-property, 
that  on  activation  the  restrictions  on  active  processes  be  satisfied. 

For  any  SDW  of  on  active  process's  descriptor  segment,  the  current- 
level  of  the  irocess: 

• must  dominate  the  level  of  a segment  having  the  r indicator 
on  and  the  w indicator  off  (respectively,  the  s indicator 
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on  and  the  m Indicator  off)  as  shown  for  segment-1  In 
Figure  12. a; 

• must  be  dominated  by  the  level  of  a segment  having  the  r 
Indicator  off  and  the  w Indicator  on  (respectively,  the 
s Indicator  off  and  the  a Indicator  on)  as  shown  for 
segme~it-2  In  Figure  1 2. b ; 

• must  equal  the  level  of  a segment  having  both  the  r and 
w (respectively,  s and  m)  Indicators  on  (segment-3  In 
Figure  12. c); 

• must  dominate  the  level  of  a segment  having  the  e indicator 
on  and  the  w Indicator  off  (segment-4  in  Figure  12. d). 

in  the  model,  the  ds-property  requires  that  every  current  access 
(a  triple  (subject,  object,  attribute)  In  the  current  access  set  b) 
be  permitted  by  the  current  access  permission  matrix  M (attribute  is 
an  element  of  the  (1,  j)-component  of  M).  The  exactly  analogous 
condition  in  Multics  is  required  for  the  satisfaction  of  the 
ds-property.  For  every  SOW  and  every  access  indicator  that  is  on 
in  the  SDW,  the  branch  In  the  segment's  parent  to  the  segment 
described  by  the  SDW  has  the  same  access  indicator  on.  In  Figure  13, 
ot|  - ON  Implies  g-|  * ON;  a 2 = ON  implies  B2  = ON;  and  ag  = ON  implies 
$2  = ON.  Note  that  (a^,  a2>  c»g)  * (ON,  OFF,  OFF)  and 
Bj,  e2,  $3)  = (ON,  ON,  ON)  satisfy  the  ds-property.  Note  that  the 
maximum  access  permitted  need  not  be  present  in  the  SDW.  As  before,  an 
inactive  process  Is  > >quired  to  be  described  dormantly  so  that  on 
activation  the  above  condition  holds  true. 

There  are  several  other  Important  security  properties  being 
considered  in  the  development  of  a secure  Multics.  Two  important 
correlative  properties  are  sabotage  and  communication  paths. 

"Sabotage"  in  this  context  means  the  malicious  alteration  or 
destruction  of  data,  especially  data  related  to  the  operation  of 
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Figure  12  b.  The  * -Property  for  Multics  write  (only) 


Figure  12d.  The  *- Property  for  Hu] tics  execute 


descriptor  segment 


Figure  i3.  The  ds -property  in  Multics 


critical  programs.  The  matter  of  cormunicatton  paths  centers  on  the 
possibility  of  Information  transmission  using  observable  system 
characteristics  and  a prearranged  code  to  semaphore  critical 
Information  to  an  undercleared  subject/process.  Neither  of  these 
topics  is  directly  addressed  by  the  mathematical  model,  although  both 
can  be  satisfactorily  resolved  using  the  model  as  a paradigm; 
discussion  of  these  security  properties  is  included  in  the  section 
FURTHER  CONSIDERATIONS. 

RULES  OF  OPERATION  FOR  A SECURE  MULTICS 

Kernel  primitives  for  a secure  Multics  will  be  derived  from 
a higher  level  user  specification  and  will  serve  to  match  the  user 
specification  to  the  particulars  of  the  Multics  architecture.  Current 
planning  is  based  on  the  desire  to  change  the  Multics  architecture 
as  little  as  possible;  this  will  account  to  a large  extent  for 
radical  differences  in  form  between  actual  kernel  primitives  and 
the  rules  cf  the  model. 

In  the  interests  of  exposition  and  better  understanding,  a set 
of  imaginary  kernel  primitives  is  presented  here.  They  are  essentially 
a transliteration  of  the  model  rules  using  Multics  terminology  and 
elements.  In  this  exposition  the  get-access  rules  of  the  model  are 
translated  into  separate  kernel  functions,  one  for  each  of  read, 
wrlte-or.ly  write,  execute  attributes  of  the  model.  In  Multics  the 
current  operation  is  such  that  only  one  access  function  serves:  when 
a segment  fault  occurs  (for  example,  as  a result  of  a load  or  store), 
an  SDW  is  created,  if  possible  and  allowable,  wi th  all  allowable  bits 
on  (the  r,  e,  and  w indicators)  which  are  on  in  the  user's  ACL. 

Another  difference  between  the  set  of  model  rules  and  the  projected 
kernel  primitives  is  that  there  will  be  neither  a change-subject- 


47 


current-security-level  nor  a change-object-security-level  kernel 
primitive.  Nevertheless,  descriptions  of  these  rules  as  well  as  the 
other  nine  rules  of  the  model  will  be  given  here. 

For  purposes  of  exposition  each  Informally  speclflsd  kernel 
function  Is  given  a name  of  the  form  kernel  function  1 (kfl)  v.lth 
kfl  corresponding  the  rule  1,  kf2  corresponding  to  rule  2,  and  so 
forth.  Objects  will  be  considered  to  be  data  segments;  similar 
operations  would  pertain  for  other  objects. 
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Request  has  the  elements: 

(a)  get-access 

(b)  process-id 

(c)  segment-id 

(d)  read 

Process  process-id  requests  that  access  to  data  segment 
segment-id  in  usage  mode  read  be  enabled. 

The  following  conditions  are  checked: 

(i)  the  ACL  (in  the  directory  segment  which  is  the  parent  of 
segment-id  unless  segment-id  - Root)  lists  process-id  with 
read  usage  (for  segment- i d) . 

(ii)  the  security  level  of  process-id,  as  given  in  the 
security  level  table,  dominates  the  security  level  of 
segment-id,  as  given  in  the  branch  extension  in  the 
directory  segment  which  is  the  parent  of  segment-id. 

(Ill)  process- id  is  a trusted  subject  or  the  current  security 
level  of  process-id,  as  given  In  the  current  security 
level  table,  dominates  the  security  level  of  segment-id. 

If  conditions  (1)  - ( i i 1 ) are  met,  then  a segment  descriptor 
word  (SOW)  is  added  to  the  descriptor  segment  of  process-id.  The 


fIf  the  SOW  already  exists,  then  the  following  actions  are  still 
appropriate --essentially  the  appropriate  access  mode  bit  is  turned  on 
in  the  existing  SOW.  This  remark  pertains  in  following  rules  also. 
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SOW  has  the  read  bit  on.  Is  pointed  to  by  a temporary  pointer  register 
(TPR),  and  points  to  segment-id.  The  prccess-ld  receives  an  affirmative 
response. 


Otherwise  process-id  receives  a negative  response  from  the 
kernel. 
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kernel  function  2:  get-write-only 

Request  has  the  elements: 

(a)  get-access 

(b)  process-id 

(c)  segment-id 

(d)  write. 

Process  process -Id  requests  that  access  to  data  segment 
segment-  Id  In  usage  mode  write  be  enabled. 

l'h . following  conditions  are  checked: 

(I)  the  ACL  in  the  directory  segment  which  is  the  parent 
of  segment-id  lists  process-id  with  write  usage. 

(II)  process-id  Is  a trusted  subject  or  the  security  level 
of  segment-id  dominates  the  current  security  level  of 
process-id. 

If  conditions  (i)  - (11)  are  met,  then  a SDW  is  added  to  the 
descriptor  segment  of  process-id.  The  SDW  has  the  write  bit  on,  is 
pointed  to  by  the  TPR,  and  points  to  segment-id.  The  process 
process-id  receives  an  affirmative  response. 

Otherwise  process-id  receives  a negative  response  from  the 
kernel . 
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kernel  function  3:  get-execute 

From  the  viewpoint  of  usefulness  (not  security),  this  function  is 
appropriate  only  if  the  segment  identified  in  the  request  for  access  is 
a procedure  segment. 

Request  has  the  elements: 

(a)  get-access 

(b)  process- id 

(c)  segment-id  (procedure-id) 

(d)  execute 

Process-id  requests  that  execute  access  to  procedure-id  be 
enabled. 

An  appeal  to  rule  kfl  is  made  with  "execute"  replacing  "read" 
in  condition  (i)  and  in  the  action  description. 
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kernel-function  4:  qet- read-write 


One  of  a number  of  possible  forms  for  kf4  is  shown  here. 


Request  nas  the  elements: 


(a)  get-access 

(b)  process-id 

(c)  segment-id 

(d)  read  and  write 


Process-id  requests  that  read  and  write  access  to  segment-id  be 


enabled. 

Action  of  kf4: 

(a)  appeal  to  kfl 

(b)  if  response  from  kfl  is  affirmative  then  appeal  to 
kf2;  otherwise  response  is  negative 

(c)  if  response  from  kf 2 is  affirmative,  then  response 
is  affirmative;  otherwise,  response  is  negative. 


kerneV  function  5:  release-read/execute/wri te 


Request  has  the  elements: 

(a)  release-access 

(b)  process- id 

(c)  segment-id 

(d)  usage  attribute 

Process- id  requests  that  read,  execute,  or  wri te  access  to 
segment-id  be  disabled. 

The  read,  execute,  or  write  bit  in  the  SDW  pointed  to  by  TPR 
is  turned  off.  If  no  other  access  bits  are  on,  then  the  SDW  is 
removed  from  the  descriptor  segment  of  process-id. 
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kernel-function  6:  gi ve-read/execute/wri te 


Request  has  the  elements: 


give-access 
requestlng-process-id 
receiving-process -Id 
segment- id 

usage-attribute  (read, 


>cute,  or  write) 


Requesting- process- id  gives  to  receiving-process-id  usac 


attribute  access  to  segment-id. 


The  following  conditions  are  checked: 

(i)  neither  the  parent  of  segment-id  nor  the  segment 
segment- id  itself  is  the  root  of  the  directory 
hierarchy  and  the  SDW  for  the  parent  of  segment-id 
has  the  write  indicator  on. 


(ii)  the  segment  segment-id  is  the  root  object  of  the 
directory  hierarchy  or  is  directly  inferior  to  the 
root  and  requesting-process-id  is  allowed  to  give 
access  permission  to  the  segment  in  the 
current  state. 


If  either  condition  (i)  or  condition  (ii)  is  met  and  segment-id 
is  not  the  root  object,  then  an  entry  is  added  to  the  ACL  in  the 
directory  segment  which  is  the  parent  of  segment-id;  this  ACL  lists 
receiving-process -id  with  usage-attribute  usage  (to  segment-id).  If 
condition  (ii)  is  met  and  segment-id  is  the  root,  then  permission 
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for  recelvlng-process-ld  to  access  segment-id  In  usage-attribute 
mode  Is  recorded.  Requestlng-process-ld  receives  an  affirmative 
response. 

Otherwise  requestlng-process-id  receives  a negative  response. 
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kernel -function  6:  give“read/execute/wr1te 

Request  has  the  elements: 

(a)  access 

f>  ' requesting-process-id 

(c)  receiving-process -Id 

(d)  segment- id 

(e ) usage-attribute  (read,  execute,  or  write) 

Requesting- process- id  gives  to  receiving-process- id  usage 
attribute  access  to  segment-id. 

The  following  conditions  are  checked:  ] 

I 

<1 

(i)  neither  the  parent  of  segment-id  nor  the  segment 
segment- id  Itself  is  the  root  of  the  directory 
hierarchy  and  the  SDW  for  the  parent  of  segment-id 
has  the  write  indicator  on. 

( i 1 ) the  segment  segment-id  is  the  root  object  of  the 
directory  hierarchy  or  Is  directly  inferior  to  the 
root  and  requesting-process-id  is  allowed  to  give 
access  permission  to  the  segment  in  the 

current  state.  j 

| 

If  either  condition  (i)  or  condition  (ii)  is  met  and  segment-id  j 

is  not  the  root  object,  then  an  entry  is  added  to  the  ACL  in  the 
directory  segment  which  is  the  parent  of  segment-id;  this  ACL  lists 
receiving-process-id  with  usage-attribute  usage  (to  segment-id).  If 
condition  (ii)  is  met  and  segment-id  is  the  root,  then  permission 
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for  recelvlng-process-ld  to  access  segment-id  In  usage-attribute 
mode  1 5 recorded.  Requestlng-process-ld  receives  an  affirmative 
response. 

Otherwise  requestlng-process-ld  receives  a negative  response. 


[ 

I 


\ 

i 

[ 
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kernel -function  7:  resclnd-read/execute/wrlte 


Request  has  the  elements: 

(a'  resclnd-access 

(b)  requestlng-process-id 

(c)  receiving  process-id 

(d)  segment-id 

(e)  usage-attribute 


Requestlnq-process-ld  takes  from  receiving-pro cess-id  usage- 
attribute  access  to  seqment-ld. 

The  conditions  checked  are  the  same  as  the  conditions  of  kf6 
except,  of  course,  "rescind"  replaces  "give"  in  condition  (1i). 

If  either  condition  (i)  or  condition  (ii)  is  met,  then  the  usage- 
attribute  is  removed  from  tne  receiving-process-id's  ACL  entry  in  the 
directory  segment  which  is  the  parent  of  segment-id;  If  no  other 
usage  attributes  are  left  in  this  entry,  then  the  entry  is  deleted. 
Requesting-process-ld  receives  an  affirmative  response. 

Otherwise  a negative  response  is  given. 


kernel -function  8:  create-object 


Request  has  the  elements: 

(a)  genera te-leaf-segment 

(b)  process-id 

(c)  segment-id 

(d)  security-level  (sec-level) 

Process  process-id  requests  that  a segment  be  added  to  the 
directory  hierarchy  directly  below  directory  segment  segment-id;  the 
added  segment  is  requested  to  have  level  sec-level . 

The  following  conditions  are  checked: 

(i)  the  SDW  in  the  descriptor  segment  corresponding  to  the 
directory  segment-id  has  the  w bit  turned  on. 

(ii)  sec-level  dominates  the  security  level  of  segment-id, 
which  is  recorded  in  the  branch  to  segment-id,  found 
in  its  parent  directory. 

If  conditions  (i)  - (ii)  are  met,  then  a branch  is  created  in 
segment-id  to  the  created  segment,  using  a supplied  name,  say 
new- segment;  the  level  of  new-segment  is  set  to  sec-level.  The 
process  process-id  receives  an  affirmative  response. 

Otherwise,  process-id  receives  a negative  response  from  the 
kernel . 
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kernel  function  9;  delete-object-group 


Request  has  the  elements: 

(a)  process-id 

(b)  segment-id 

Process-Id  requests  that  segment-id  be  deleted  (detached  from 
the  directory  hierarchy).  This  results  In  deletion  of  all  segments 
In  the  directory  hierarchy  which  are  Inferior  to  segment-id. 

The  following  condition  is  checked: 

(i)  same  conditions  as  condition  (1)  of  kf6. 

If  the  condition  is  met,  then  the  following  recursive  algorithm 
is  invoked: 

(i)  set  current-segment-id  to  segment-id. 

( i 1 ) if  there  are  no  branches  in  current-segment-id  then 
do  the  following: 

(a)  delete  all  SDWs  which  refer  to  current-segment-id. 

(b)  delete  current-segment-id  from  the  hierarchy. 

(c)  delete  the  branch  of  current-segment-id  in 
its  parent  directory  segment. 

(d)  set  current-segment-id  to  the  segment-id  of  the 
parent  of  the  segment  just  deleted. 

(e)  if  current-segment-id  refers  to  the  parent  of 
segment-id  (the  original  segment-id),  then 
finished;  else  do  action  ( 1 i ) . 
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otherwise,  set  current-segment  Id  to  the  segment-id 
given  In  any  branch  and  do  action  (11). 
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kernel-function  10:  change-subject-current-security- level 
Request  h^s  the  elements: 

(a)  process-id 

(b)  sec-level 

Process  process- Id  requests  that  Its  current  security  level  be 
changed  to  sec-l-vol. 

The  following  renditions  are  checked: 

(I)  process-id  Is  listed  In  a table  of  trusted  processes 
or  for  every  SOW  for  a segment  In  the  descriptor 
segment  for  process- Id, 

• If  the  r Indicator  is  on,,  sec-level  dominates  the 
levfci  of  the  segment,  and 

• If  the  w indicator  Is  on,  sec-level  Is  dominated 

£ 

by  tfie  level  of  the  segment. 

(II)  the  security  level  of  process-id,  given  In  the  security 
level  table,  dominates  sec-level. 

If  conditions  (1)  - (11)  are  met,  then  the  current  security 
level  of  process-id  in  the  current-security-level  table.  Is  changed 
to  sec-level.  The  process  process-id  receives  an  affirmative 
response. 

f 

i 

Otherwise,  process-id  receives  a negative  response  from  the 
! kernel . 
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kernel -function  11:  rhange-object-securi  ty- level 

Request  has  the  elements: 

(a)  revise-security-level 

(b)  process-id 

(c)  segment- Id 

(d)  sec-level. 

Process  process-id  requests  that  the  security  level  of  segment- Id 
be  revised  to  th-;  value  sec-level . 

The  following  conditions  are  checked: 

(i)  prores$-1d  is  a trusted  process  and  the  current  security 
level  of  process-id,  recorded  In  the  current  security 
level  table,  dominates  the  security  level  of  segment-id, 
found  <n  the  branch  to  segment-id  In  segment-id's  parent 
directory, 

(ii)  for  every  SOW  for  a process  and  segment-id  that  has  the 
r Indicator  on,  the  current  level  of  process  in  the 
current-security-level  table  dominates  sec-level. 
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(Ill)  for  every  SDW  for  a process  and  segment-id  that  has  the 
w Indicator  on,  sec-level  dominates  the  current  level 
of  process  , 

( 1 v ) the  security-level  field  of  every  branch  In  segment-id 
dominates  sec-level  and  sec-level  dominates  the  level  of 
the  parent  of  segment-id, 

(v)  procr:s-1d  Is  allowed  to  change  segment-id's  security 
level . 


If  conditions  (1)  - (v)  are  met,  then  the  security-level  field 
of  the  branch  to  segment-id  found  In  the  parent  directory  of  segment-id 
is  changed  to  sec-level.  The  process  process-id  receives  an 
affirmative  response. 

Otherwise,  process-id  receives  a negative  response  from  the 
kernel , 
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SECTION  IV 


FURTHER  CONSIDERATIONS 

INTRODUCTION 

In  this  section  we  discuss  topics  that  are  related  to  the  mathe- 
matical model  only  indirectly.  The  first  of  these  is  the  concept  of 
"trusted  subjects":  an  attempt  is  made  here  to  explicate  the  func- 

tional characteristics  of  trusted  subjects  and  the  formal  justifica- 
tion required  to  make  a subject  "trusted."  The  other  topics  discussed 
are  problems  that  might  admit  modeling  in  an  extension  of  the  current 
model  but  that  have  not  been  investigated  in  this  way.  These  topics 
are  "communication  paths"  (the  indirect  disclosure  of  sensitive  in- 
formation), "sabotage"  (the  deliberate  alteration  or  destruction  of 
sensitive  information),  and  "integrity"  (a  property  addressing  approved 
modifi cation  of  information). 

The  topics  covered  in  this  section  become  important  in  the 
certification  and  implementation  phases  of  the  development  of  a secure 
computer  system.  Moreover,  resolutions  of  the  problems  have  not  been 
devised  as  yet.  H^rce,  the  discussion  in  this  sectior  'ill  attempt 
to  identify  the  issues,  making  use  of  specific  examples  in  a Multics 
environment  in  the  exposition.  The  discussion  will  of  necessity  not 
provide  definitive  answers1  the  intent  is  to  formulate  the  questions. 

TRUSTED  SUBJECTS 

Within  the  model,  trusted  subjects  are  those  subjects  not 
constrained  by  the  *-property.  Outside  the  model,  a subject,  to  be 
designated  "trusted,"  must  be  shown  net  to  consummate  the  undesirable 
transfer  of  high  level  information  that  *-property  constraints  pre- 
vent untrusted  subjects  from  making.  The  demonstration  that  a process 
can  be  a "trusted"  process  is  the  concern  of  this  discussion. 


m 
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It  is  important  to  emphasize  here  that  a "trusted  subject"  is 
only  required  not  to  copy  high-level  information  into  a low-level 
segment  (object).  It  is  also  important  to  guarantee  that  the  operation 
of  a trusted  subject  (procedure)  cannot  be  used  as  a medium  of  clan- 
destine communication.  That  is,  trusted  subjects  are  not  involved  in 
communications  paths,  a topic  we  will  discuss  in  a later  section.  The 
focus  here  is  on  "trustedness"  — not  copying  information  into  in- 
appropriate objects. 

A sufficient  (but  not  necessary)  condition  for  declaring  a 
process  trusted  is  that  the  process  is  conceptually  equivalent  to  a 
set  of  subprocedures  each  of  which  performs  an  operation  constrained 
by  the  ^-property  and  ther.  chooses  a successor.  For  example,  the  simple 
procedure: 

P:  DO  WHILE  A; 

IF  B THEN  D:  = E; 

ELSE  F:  = G; 

END; 

H:  = I; 

END; 

is  conceptually  equivalent  to  the  subprocedures  PI,  . . . „ P6  defined 
and  organized  as  shown: 
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If  none  of  the  subprocedures  violates  the  ^-property  (using  the  minimal 
conceptual  current  access  for  each  Pi),  then  P itself  would  not 
violate  the  *-property,  even  if,  say,  A were  top  secret  and  H were 
confidential . 

Two  remarks  are  in  order.  First,  the  division  into  subprocedures 
here  is  possibly  overdone.  If,  for  instance,  D,  E,  and  F are 
secret,  B is  confidential,  and  G is  unclassified,  then 
subprocedures  P2,  P3,  P4  and  P5  could  be  combined  into  a single 
subprocedure  P7.  P could  then  be  represented  as  follows: 


Since  P7  does  not  violate  the  *-property,  P could  be  shown  not 
to  violate  *-property  using  this  subdivision  also.  The  merits  of 
subdivision  to  instruction  level  vs.  subdivision  only  as  needed  can 
be  worked  out  to  suit  individual  tastes;  the  result  will  be  the  same 
in  either  case. 

The  second  point  to  be  made  about  tbrs  type  of  demonstration  is 
that  the  condition  that  the  process  be  equivalent  to  a number  of 
subprocedures  obeying  the  *-property  constraints  is  not  necessary  for 

the  establishment  of  crusted  processes.  In  particular,  if  and  when 
a semantically  correct  "write-down"  from  a hjgh-level  file  to  a 
low-level  file  can  be  guaranteed,  the  process  responsible  could  be 
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demonstrated  to  be  trusted.  The  latter  situation  leads  directly  to 
the  formulary  concept,  which  Is  treated  at  some  length  elsewhere  [20]. 

EXTRA-MODEL  SECURITY  PROPERTIES 

Communication  Paths 


The  first  extra-model  security  property  to  be  discussed  is 
comnuni cations  paths.  By  this  term  is  meant  the  indirect  disclosure 
of  sensitive  information,  as  opposed  to  the  direct  disclosure  of 
information  which  is  addressed  by  the  security  properties  of  the 
model.  Indirect  disclosure  can  be  effected  by  transmitting  data 
piecemeal  using  observable  system  characteristics  as  the  code  medium. 

A large  number  of  observable  system  characteristics  can  be 
used  to  transmit  information,  frequently  a bit  at  a time.  Possibly 
the  most  difficult  medium  to  rule  out  as  a communication  path  is 
real  time:  intervals  of  real  time,  delimited  by  prearranged 

observable  events  and  varied  by  using  the  system,  can  be  used  to 
transmit  information  in  bit  strings  (see  Figure  14). 
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Figure  14.  Communication  Using  Real-Time  Intervals 
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Examples  of  system  uses  to  vary  real-time  intervals  are  computing- 
to-IO  ratios  and  paging  rate.  There  is  the  possibility  that 
synchronous  paths  cannot  be  entirely  eliminated  from  any  system  that 
shares  data.  Examples  of  this  type  of  communication  can  be  found  in 
B.  W.  Lampson's  discussion  of  system-performance  information  channels 
[21]  and  Lipner's  discussion  of  improvements  (viz.,  lowering  bandwldths 
of  paths)  [23]. 

Indirect  communication  using  nonsynchronous  paths  remains  a 
very  complicated  problem.  Since  a nonsynchronous  path  must  make 
use  of  files,  system  variables,  and  the  like  to  transmit  a message, 
close  and  careful  consideration  of  every  possible  action  in  a system 
will  discover  every  nonsynchronous  communication  path.  Within  the 
model,  however,  there  is  no  guidance  for  this  enumerative  exercise. 

In  addition,  the  exercise  itself  can  involve  very  subtle  interactions 
of  a number  of  objects.^  Two  examples  will  be  presented  to  demonstrate 
the  subtleties  involved.  Both  examples  i.  volve  the  capability  to 
create  and  destroy  objects. 


Suppose  in  the  first  instance  that  secret-process  can  create 
and  destroy  confidential  segments  whose  existence  can  be  detected  by 
confidential -process  (see  Figure  15). 


(secret- process) 


creates/destroys 


I confidential -segment \<  -e<L"  £r-  - Confidential -proces* 

not  seen  by  — ^ 


Figure  15.  An  Example  of  a One-Bit  Message 
+A  description  of  a solution  to  this  problem  may  be  found  in  [22]. 
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A string  of  such  confidential  segments  could  easily  be  used  to 
transmit  a bit  string  to  a confidential  process,  by  destroying  those 
segments  which  correspond  to  zeroes  In  the  bit  string  (Figure  16). 
This  situation  is  clearly  unJesIrable. 


Figure  16.  The  Transmission  of  the  Bit-String  10110 
For  the  second  example,  suppose  that  confidential -process  is 


denied  a request  to  destroy  a confidential  directory  If  there  is  a 


t 

I 

Figure  17.  Another  One-Bit  Message 
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In  this  case,  secret-process  can  alter  the  system's  response  to  a 
request  to  destroy  the  confidential  segment  by  creating  or  destroying 
a subordinate  secret  segment.  This  situation  too  Is  undesirable. 

Neither  of  these  situations  is  possible  in  the  secure  Multics 
design.  The  first  example  is  disallowed  by  compatibility:  to 
destroy  a segment  one  must  read/write  the  segment's  parent  which,  by 
compatibility,  has  a level  lower  than  or  equal  to  that  of  the 
segment  Itself.  The  second  example  is  disallowed  because  the 
destruction  of  objects  specified  by  rule  9,  delete-object-group, 
does  not  prohibit  a confidential  process  from  destroying  a secret 
object  inferior  to  the  root  object  of  the  destroyed  subtree. 

However,  the  care  with  which  creation  and  destruction  algorithms 
must  be  designed  illustrates  the  complexities  of  enumerating  the 
full  list  of  objects  which  can  be  used  in  nonsynchronous  communications 
paths. 

Sabotage  and  Integrity 

Sabotage,  in  this  context,  means  undesired  alteration  or 
destruction  of  information  by  the  purposeful  action  of  an  agent; 
integrity  is  a property  determined  by  approved  modification  of 
information.  To  clarify  the  meaninqs  of  the  two  terms  "sabotage" 
and  "integrity"  the  intended  meanings  of  the  adjectives  "undesired" 
and  "approved"  must  be  explicated.  An  alteration  or  destruction  of 
information  is  undesirable  if  the  intended  and  well-intentioned 
users  of  the  system  deem  it  so;  a modification  is  approved  if  these 
same  users  consider  the  resulting  semantic  content  of  the  modified 
information  to  be  correct.  Hence,  in  the  context  of  information 
stored  in  a computer-based  information  system,  sabotage  and 
integrity  are  closely  related 
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An  act  of  sabotage  can  have  two  principal  effects:  Improper 
functioning  of  the  system  and  incorrect  semantic  content.  An 
Integrity  policy  attempts  to  prevent  acts  of  sabotage  within  the 
Information  system  or  to  localize  the  effects  to  an  acceptable 
degree. 

Work  on  a model  or  Integrity  policy  Implementation  Is  proceeding 
at  MITRE  [23].  A major  problem  Is  to  specify  an  acceptable  and 
appropriate  policy  to  govern  the  modification  of  data  segments.  We 
consider  here  a simple  model  of  Integrity,  leaving  policy  largely 
unspecified.  In  order  to  further  the  exposition  of  the  problem. 

Suppose  that  a set  S of  "integrity  levels"  is  given:  consider 
as  an  example  the  set: 

nonsensitive  < sensitive  < critical  < very  critical 

The  semantics  of  these  terms  Is  suggestive;  the  integrity  policy  Is, 
nevertheless,  not  specified  by  them  since  they  are  not  formally 
defined.  Suppose  further  that  Integrity  level  functions,  analogous 
to  security  level  functions,  are  defined: 

Is:  {subjects! ►{Integrity  levels}  and 

IQ:  {objects}  — ■►{Integrity  levels}. 

Ic(subject)  denotes  the  maximum  Integrity  level  of  an  object  that 
subject  Is  allowed  to  modify;  IQ(object)  denotes  the  minimum  level 
of  any  subiect  that  is  allowed  to  modify  object. 

Redefine  a state  v of  the  system  by  the  Inclusion  of 
I - (Is.  I0): 
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v « (b,  M,  f,  I,  H). 


We  can  define  a simple- Integrity-property  (s 1 -property ) , analogous  to 
the  ss-property,  as  follows: 

a state  satisfies  the  si-property  provided  for  every  current 
alter-access  (subject,  object,  alter-attrlbute) , the 
integrity  level  of  subject  (Ig(subject) ) is  greater  than  or 
equal  to  the  integrity  level  of  object  (I0(object)). 

More  formally,  v = (b,  M,  f,  I,  H)  satisfies  the  si-property 
provided: 

[(Si , Oj,  x)  in  b and  in  {w,  aj] 
implies  Ig(S^)  £ IQ(0j). 

There  is  an  alternative  formulation  of  the  si-property,  as  there  is 
for  the  ss-property: 

the  state  v = (b,  M,  f,  I,  H)  satisfies  the  si-property 
provided  every  (S.,  0.,  x)  in  b satisfies  the  simple- 

J 

integrity  condition  relative  to  I (SIC  rel  I);  (S^,  0^,  x) 
in  b satisfies  SIC  rel  I provided  (x  - w or  x * -a) 
implies  that  IS(S^)  £ IQ(0j ) . 

Given  the  above  extension  of  the  model,  needed  modifications 
to  the  rules  of  operation  are  obvious;  moreover,  intuition  indicates 
that  assuring  the  si-property  systemically  is  inductive  and  can  be 
accomplished  by  demonstrating  si -property  preservation  over  one 
state  change  (as  is  the  case  for  secure  state  preservation).  No 
analogue  to  the  ‘-property  exists,  since  the  problem  of  information 
transfer  within  the  realm  of  disclosure  has  no  analogue  in  the 
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realm  of  sabotage.  Finally,  an  Inverse  compatibility  property  for 
the  hierarchy  seems  attractive;  this  would  dictate  that  the 
Integrity  level  of  objects  be  monotone  non-increasing  on  paths  away 
from  the  root.  This  latter  property  relates  to  "localizing"  damaging 
effects  of  sabotage  action.  Actual  sabotage  of  sensitive-directory 
In  Figure  18  Indirectly  sabotages  Inferior  segments,  which  are 
necessarily  nonsensitive  or  sensitive  under  inverse  compatibility; 
the  effect  of  sabotaging  sensitive-directory  by  a sensitive  process 
running  amok  would  not  extend  to  Its  parent,  critical -directory, 
nor  to  unrelated  segments  such  as  critical-segment,  sensitive-segment, 
and  nonsensi five-segment. 
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Figure  18.  The  Subtree  Affected  by  Sabotage  of  S pr  ltive-Di rectory 
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APPENDIX 


introduction 


The  formal  mathematical  model  Is  presented  In  this  Appendix. 

No  interpretation  or  explanation  Is  offered,  except  as  subsequently 
noted.  The  Intended  Interpretations  and  correspondences  to  Multlcs 
architectural  elements  are  giver,  in  the  body  of  this  report.  In 
the  section  of  this  Appendix  on  rules,  a narrative  statement  of  each 
rule  is  given  In  order  to  reduce  the  reader's  Inconvenience  In 
dealing  with  highly  abstract  symbology  and  in  order  to  provide  a 
natural  language  statement  of  Intention  by  which  errors  or  policy 
misdirections  In  the  formal  statements  may  be  more  easily  discovered. 

Elements 


The  elements  of  the  mathematical  model  are  presented  In  Table  1. 
Some  items  are  not  self-explanatory  and  they  are  explained  here. 

partial  ordering  relation  » : 

A relation  R is  a partial  ordering  relation  if  R is 
reflexive,  antisymmetric,  and  transitive. 

Suppose  that  U is  a set  and  R is  a binary  relation  defined 
on  U,  with  elements  of  U denoted  by  small  letters  a,  b,  c,  . . 
etc. 


reflexive:  R Is  reflexive  If  xRx  for  each  x in  U. 
antisymmetric:  R is  antisymmetric  if  [xRy  and  yRx]  implies 
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x * y (x  Is  Identically  y)  for  each  x and  y In  U. 

(In  other  words,  we  have  xf(y  and  yRx  (symmetry)  only 
In  case  x * y. ) 

transitive:  R Is  transitive  If  [xRy  and  yRz]  Implies 

xRz  for  each  x and  y and  z In  U. 

L - VL-| , L2,  . . Lp>  where  Lj  * (Cj , K)  and  Cj  Is  In 
C and  K Is  a subset  of  K.  Define  the  relation  x>  on  L as 
fol lows : 

(Li , L.)  e jo  e L.  » Lj  s (C..  K)  » (Cjt  K' ) Iff 

(I)  C1  * Cj,  and 

(II)  k2k'. 

Since  both  ">"  and  "d'  are  partial  orderings,  a straightforward 
argument  shows  that  is  also  a partial  ordering. 

Suppose  C * (S,  C,  U > , S > C > U,  and  K e (Kj,  Kg) 
and  L-j  a (S,  l^}),  L2  (S,  Lj  * (C»  {^-j*  l^})* 

I4  = (C, {K^ } ) , Lg  = (S,  { K2 , Kj),  Lg  = ^7  ^ (^»  (Kj}). 

The  partial  ordering  of  these  elements  of  L is  illustrated  as  a 
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aagggnrs? " 


Suppose  [U,  R]  Is  a partially  ordered  system.  An  element 
m In  U Is  called  a minimal  element  in  U if  mRx  implies  xRm 

for  each  x In  U;  If  m is  unique  it  is  called  a minimum.  For 

30 ] i as  in  the  previous  example,  there  are  three  minimal 
elements,  (U,  K-j ) , (U,  l^),  and  (U,  K^)  and  there  is  no  minimum. 

If  K'  = K u ($},  then  (U •<p)  is  a minimum  In  [C  x *',»]. 

D 

the  notation  A : 

Suppose  A and  B are  sets.  The  notation  A^  denotes  the  set 

of  all  functions  from  B to  A.  Suppose  A = (a,  b}  and  B ■ {1 , 2}; 
R 

then  A consists  of 

- (0,  a),  (2,  b)}, 

f2  = {(1.  b),  (2,  a)}, 

f3  = {(1 , a),  (2,  a}},  and 

f4  ■ {(1.  b),  (2,  b)}. 

rartesian  product: 

Suppose  A and  B are  sets.  The  cartesian  product  of  A and 

B,  denoted  A x B,  is  defined  by 

A x B = {(a,  b):  a e A and  b e B}, 

i.e.,  A x B is  the  set  of  all  ordered  pairs  of  the  form  (a,  b) 
where  a Is  in  A and  b is  in  B.  Suppose  A = {a,  b)  and 
B = {1,  2}.  Then  A * B = {(a,  1),  (a,  2),  (b,  1),  (b,  2)}.  Notice 

that  B x A = {(1 , a) , (2,  a),  (l,b),  (2,  b)>  M«B.  Notice 

also  that  f|  c B x A,  f^  defined  above. 
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the  notation  PX: 

Suppose  X Is  a set,  say  Xs  {a,  b,  c>.  PX  means  the  set  of 
all  subsets  of  X.  In  this  case,  PX  * U,  (a),  (b>,  {c},  {a,  b}, 
{a,  c),  {b,  c},  (a,  b,  c}}  where  $ denotes  the  empty  set. 

hierarchies: 

Suppose  H£  (PO) ^ where  0 * (0^,  02,  0^,  0^,  05>.  Restrict 
membership  in  H by  the  conditions  (1)  and  (2)  (see  Table  1,  entry 
for  H).  Define  H c H as  follows: 

H = {(0r  {02,  0 ),  (02,  *),  (03  (04,  05>),  (04,  ♦),  (05,  ♦)}. 

H can  be  described  also  by  a diagraph: 


Condition  (1)  rules  out  a structure  such  as 
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and  condition  (2)  rules  out  a structure  such  as 


If  an  element  of  H Imposes  a forest  structure  on  the  objects  with 
exactly  one  tree,  as  in  the  example,  we  Identify  the  root  of  the 
tree  by  the  notation  Op.  If  H Is  a tree  structure  then  Op  is 
that  object  in  0 for  which 


H(0r)  i * and 

0R  t H(0)  for  any  0 e 0. 


If  Oj  is  an  object  in  0 then  0S^.» 
respect  to  H such  that  0^  c H(°s(j))i 
"superior"  to  0,  by  H. 

J 


denotes  that  object  with 
in  other  words  is 


System 


Suppose  that  WCRxD*v*V.  The  system 
L (R,  D,  W,  zQ)c  X x y x Z Is  defined  by 

(x,  y,  z)  e £(R,  D,  W,  zq)  iff 

(xt,  yt,  zt,  e W for  each  t in  T, 

where  zq  is  an  initial  state  of  the  system,  usually 

of  the  form  ($,  M,  f,  H). 


Properties 


i 

i 


We  define  properties  in  terms  of  the  members  of  a state  sequence. 
We  then  say  that  the  system  has  a specified  property  if  each  state  of 


every  state  sequence  of  the  system  has  the  property.  The  following 
notation  Is  defined. 


b(S:  x,  ....  z)  ■ (0:  (S,  0,  x)  e b or 

(S,  0,  £)  e b or 


(S,  0,  z)  e b> 


simple-security 


A state  v * (b,  M,  f,  H)  satisfies  the  simple-security  property 
(ss -property)  Iff 


S < S->[(0  g b (S:  r,  *))  ->(f$(S)  * fQ(0))]. 


It  is  convenient  also  to  define: 

(S,  0,  x)  c b satisfies  the  simple  security  condition  relative 
to  f (ssc  rel  f)  iff 

(I)  x - e or  a , or 

(II)  x s r or  w and  f$(S)  » fQ(0). 

Then  it  is  easily  shown  that  a state  v * (b,  M,  f,  H)  satisfies 
ss-property  iff  each  (S,  0,  x)  e b satisfies  SSC  rel  f. 


♦-property 

Suppose  S'  is  a subset  of  S.  A state  v « (b,  M,  f,  H) 
satisfies  the  *-property  relative  to  S'  Iff 
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(0  e b{S:  a))  -MfQ(0)  » fc(S)) 

(0  c b(S:  w))  «o  (fQ(0)  - fc(S)) 

(0  e b(S:  r))->(fc(S)  » fQ(0)). 

An  Immediate  consequence  Is:  If  v satisfies  ^-property  rel  S' 

and  S e S'  then 

[0j  e b(S:  a.)  and  0^  e b(S:  r)]  ->f0(^)  » fo(0k). 
discretionary-security 

A state  v - (b,  M,  f,  H)  satisfies  the  discretionary-security 
property  (ds -property)  iff 

(S^  i 0 j i x ) c b x e j« 
secure  system 

A state  v is  a secure  state  iff  v satisfies  the  ss-property 
and  *-property  rel  S'  and  ds-property.  A state  sequence  z is 
a secure  state  sequence  Iff  z is  a secure  state  for  each  t e T. 
Call  (x,  y,  z)  € £(R,  D,  W,  zQ)  an  appearance  of  the  system. 

(x,  y,  z)  c £(R,  0,  W,  zQ)  is  a secure  appearance  iff  z is  a 
secure  sequence.  F ‘ ially,  £(R,  D,  W,  zQ)  is  a secure  system  iff 
every  appearance  of  £(R,  0,  W,  zQ)  is  a secure  appearance.  Similar 
definitions  pertain  for  the  notions. 

( i ) the  system  .°(R,  0,  W,  zq)  satisfies  the  ss-property, 

(ii)  the  system  satisfies  *~property  rel  5’,  and 

(iii)  the  system  satisfies  the  ds-propert>. 
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Definition  of  Rule 


A rule  is  a function  o:  R * V ■>  D k V,  A rule  therefore 
associates  with  each  request-state  pair  (Input)  a decision-state 
pair  (output). 

A rule  p is  secure-state-preserving  Iff  v*  is  a secure 
state  whenever  p (Rk>  v)  - (Dm,  v*)  and  v is  a secure  state. 
Similar  definitions  pertain  for  the  notions 

(1)  p Is  ss-property-preserving, 

(ii)  p is  ‘-property-preserving,  and 

( i 1 i ) p is  ds-property-preserving. 

Suppose  u = {oj,  p2»  . . .,  ps>  is  a set  of  rules.  The 
relation  W(oj)  is  defined  by 

(Rk,  Dm,  v*.  v)  c W(ui)  Iff  Dm  t ? and 

(Dm>  v*)  = p^  (R^,  v)  for  a unique  i,  1 < i ^ s. 

Theorems 


(R^,  Dj,  v*,  v)  E R x D * V x V is  an  action  of  £(R,  D,  W,  zo) 
iff  there  Is  an  appear<ince  (x,  y,  z)  of  T(R,  D,  W,  zQ)  and  some 
t € T such  that  (R.. , Dj , v*.  v)  = (xt,  yt,  zt,  z^j. 

theorem  A1 : 

£(R,  D,  W,  zQ)  satisfies  the  ss-property  for  any  initial 

state  z which  satisfies  ss-property  iff  W satisfies  the  following 
o 
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conditions  for  each  action  (Rr  Dj,  (b*.  M*.  f*.  H*),  (b,  M,  f,  H)): 

(I)  each  (S,  0,  x)  « b*-b  satisfies  the  single  security 
condition  relative  to  f*  (SSC  rel  f*); 

(II)  each  (S,  0,  x)  g b which  does  not  satisfy  SSC  rel  f* 

Is  not  In  b*. 

argument: 

( «-) 

Suppose  zQ  ■ (b,  M,  f,  H)  Is  an  initial  state  which  satisfies 
ss-property.  Pick  (x,  y,  z)  « £(R,  D,  «.  zj  and  write 
zt  • (b(t).  M(t),  f(t\  for  each  t c T. 


Zj  satisfies  ss-property 


(x1#  y-i*  *1.  z ) Is  In  H.  In  order  to  show  that  z, 

I I I O M \ I 

ss-property  we  need  to  show  that  each  (S,  0,  x)  In  b1  ' 
SSC  rel  f(1*. 


satisfies 

satisfies 


Notice  that  - (b^  - b^)u(b^r>  b^)  and 

(b^  - n (b^  n ■ f.  Suppose  (S,  0,  vj  Is  In  b^\ 

Then  *1t»*:-  (S,  0,  x)  Is  In  (b(1)  - b'0))  or  is  In  (b(1)n  b(0)). 
Suppose  , >,  0,  x)  Is  In  (b^  - b^0^).  Then  (S,  0,  x)  satisfies 
SSC  rel  i ^ according  to  (1).  Suppose  (Sf  0,  x)  is  in 
(b^°'  n Then  (S,  0*  x)  satisfies  SSC  rel  f^  according 

to  (11),  Therefore  Zy  satisfies  ss-property* 


89 


If _ 1 satisfies  ss-property,  then  z^,  satisfies  ss -property. 

The  argument  given  for  "z^  satisfies  ss-property"  applies  with 
"t-1"  substituted  for  "0"  and  "t"  substituted  for  "1". 

By  Induction,  z satisfies  ss-property  so  that  the  appearance 
(x,  y,  z)  satisfies  ss-property.  (x,  y,  z)  being  arbitrary, 
r(R,  D,  W,  zQ)  satisfies  the  ss-property. 

( •>  ) 

Suppose  £(R,  0,  W,  7^)  atisfies  the  ss-property  for  any 
initial  state  zfi  which  satisfies  ss-property. 

Argue  by  contradiction.  Contradiction  yields  the  proposition 

"there  is  some  action  (x,,  y.,  z.,  z.  ,)  such  that  either 

t.  L V,  ..  “ I 


(iii) 

some  (S,  0, 

x)  in  b 

W - h 

U-l) 

does 

not 

satisfy  SSC 

rel  f*^ 

or 

(iv) 

some  (S,  0, 

x ) in 

bu-n 

which 

dees 

not 

satisfy  SSC 

rel  f(t) 

is  in 

bf> 

, i.e. 

. , is 

in  b(t_1'n 

b " 

Suppose  (iii).  Then  there  is  ome  (S,  n,  x)  <n  which 

does  not  satisfy  SSC  rel  f^)  Suppose  (iv).  Then  thare  is  some 
(S,  0,  x)  in  b^  which  does  r.  if  satis'y  sr  rel  f^'.  Therefore 
zt  does  not  satisfy  ss-property,  \x,  v,  z)  does  not  satisfy 
ss-property,  and  sc  £(R,  0,  W,  zQ)  does  not  satisfy  ss-property. 
which  contradicts  initial  assumption  of  the  argument. 
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The  argument  Is  complete. 


theorem  A2:  i'(R,  D,  . , Zq)  satisfies  the  ^-property  relative  to 
5'c  5 for  any  initial  state  zQ  which  satisfies  ^-property  relative 
to  S'  iff  U satisfies  the  following  conditions  for  each  action 


°r 

(b*. 

ft*.  1 

f*.  H*) , 

(b.  ! 

1.  f.  H)): 

(D 

for 

each 

S e S', 

(a) 

0 < 

(b*  ■ 

■ l>)(S:a) 

“> 

V(°)  * V 

(S),  and 

(b) 

0 « 

(b*  ■ 

- b)(S:w) 

-> 

V(°)  ‘ V 

(S),  and 

(c) 

0 < 

(b*  ■ 

• b)(S:r) 

-> 

f *(S)  » f * 
c v ' o 

(0); 

(ii) 

for 

each 

S € 5 ’ , 

(a  ‘ ) 

[0 

« b(S 

:a)  and 

f *(°)  * f*(S)] 

*> 

0 4 

b*(S.a) v 

and 

(b1) 

[0 

( b(S 

:w)  and 

f *(°)  t fc*(s)] 

-> 

0 4 

b*(S .w). 

and 

(c1) 

[0 

i b(S 

:r)  and 

f * 

c 

(S)  * f0*(">] 

«> 

0 4 fc*(S:r) . 


argument: 

( <-  ) 

Suppose  Zq  = (b,  M,  f,  !:)  is  an  initial  state  which  satis  ies 
♦-property  rel  5'.  Pick  (x,  y,  z)  in  I(R,  D,  l.',  Zq)  and  write 
Zt  . („<»>.  f<*>.  .;<'»)  for  each  t ( T. 
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z i satisfies  ‘-property  rel  S' 


(x.j,  y^,  z^,  zQ)  Is  in  W.  in  order  to  show  that  z^ 
satisfies  ‘-property  rel  S'  we  need  to  show  that: 


(111)  S C S'*J 


0 e b^^StaJ-of  ^(0)  50  f (^(S) 
0 c b^1  ^(S:w)-o  f ^(0)  - fC^(S) 
0 e b^(S:r)^  f°^(S)  » 


Suppose  (S,  0,  x)  t b^,  S e S',  x e {a,  w,  r}.  Then  either 
(S,  0,  x)  is  in  (b^  - b^)  or  (S,  0,  x)  is  in  (b^  n b^). 
Suppose  (S,  0,  x)  is  in  (b^  - b^).  Then  (iii)  is  satisfied 
accoraing  to  (i).  Suppose  (S,  0,  x)  is  in  b^  n h^.  Then  (iii) 
is  satisfied  according  to  ( i i ) . Therefore  z^  satisfies  *-property 
rel  S 1 . 


if  zt  ^ satisfies  ‘-property  rel  S',  then  satisfies 
‘-property  rel  S' 


The  argument  given  for  "z^ 
applies  with  "t-1"  substituted 

M *|  ii 

Cy  induction,  z satisfies 
appearance  (x,  y,  z)  satisfies 
being  arbitrary,  e(R,  D,  W,  zq) 

S' . 


satisfies  ‘-property  rel  S'" 
for  "0"  and  "t"  substituted  for 


♦-property  rel  S’  so  that  the 
♦-property  rel  S',  (x,  y,  z) 

satisfies  *-property  relative  to 


(->  ) 


Suppose  l(R,  U,  W,  Zq)  satisfies  ‘-property  relative  to  S' 
for  any  Initial  state  Zq  which  satisfies  ‘-property  rel  S'. 
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Argue  by  contradiction.  Contradiction  yields  the  proposition 


"there  Is  some  action  (xt,  yt,  z^.,  zt_-|)  such  that  either 

( 1 v)  (1)  Is  false  or 
(v)  (11)  is  false." 

Suppose  ( 1 v) . Then  there  Is  some  S e S'  such  that  (a)  is  false  or 
(b)  is  false  or  (c)  is  false.  Then  zt  does  not  satisfy  *-property 
rel  S'.  Suppose  (v).  Then  there  Is  some  S e S'  such  that  (a1)  is 
false  or  (b;)  is  false  or  (c * ) is  false.  Then  z^  does  not  satisfy 
♦-property  rel  S'.  This  leads  to  "(x,  y,  z)  does  not  saJsfy 

♦-property  rel  S'  and  so  r(R,  D,  W,  zQ)  does  not  satisfy 
♦-property  rel  S'",  which  contradicts  initial  assumption  of  the 
argument. 

The  argument  is  complete. 

theorem  A3:  e(R,  D,  ’«•!,  zq)  satisfies  the  ds-property  iff  zQ 

satisfies  the  ds-property  and  W satisfies  the  following  condition 
for  each  action  (R. , D.,  (b*,  M*,  f*,  H*),  (b,  M,  f,  H)): 

* J 

(i)  (Sa,  0a,,  x)  e b*  - b =>  X e M#*a,;  and 

(ii)  (S.  0.,,  x)  e b and  x l M*  , -e>  (S_,  0 ,,  x)  l b*. 

a a — — a y a a a 


(<=) 


If  (s»»  °a'*  x)  E ~ bl°\  * e M hy  (O.  Suppose 

a a a * a 

(S.  0,,,  x)  Eb(1,n  b^.  If  X i Ma  W , then  (S.  0,, . x)  i b(1^, 

da  — u|  d aa 

contrary  to  our  supposition.  Thus  x e 

Of  a 


93 


(S  , 0 x)  € b(i)  - (b(1>  - b(0))  U (b(1'n  b(0)).  X c M and 

a a — fi|Q 

z-j  satisfies  the  ds-property. 

(->) 


Suppose  z(R,  D,  W,  z0)  satisfies  the  ds-property. 

Argue  by  contradiction.  Contradiction  yields  the  proposition 

"there  Is  an  Initial  state  zQ  satisfying  the  ds-property  and 
there  Is  some  action  (xt,  y^,  z^,  j)  such  that  there 
is  some  (S_,  0.,,  x)  e b^  such  that  x i 

Therefore  zt  does  not  satisfy  ds-property,  (x,  y,  z)  does  not 
satisfy  ds-property,  and  so  z(R,  D,  W,  zQ)  does  not  satisfy 
ds-property,  which  contradicts  the  Initial  assumption  of  the 
argument. 

The  argument  Is  complete. 

corollary  A1 : i(R,  D,  W,  zQ)  is  a secure  system  Iff  zQ  is  a 

secure  stat-*  and  W satisfies  the  conditions  or  tf  irms  A1 , A2, 
and  A3  for  each  action. 

theorem  A4:  Suppose  w is  a set  of  ss-property-preservlng  rules 

and  Zg  is  an  initial  state  which  satisfies  ss-property.  Then 
r(R,  D,  H (w),  Zg)  satisfies  ss-property. 

argument 

Suppose  £(R,  D,  W (u>),  zQ)  does  not  satisfy  ss-property. 
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Then  there  Is  (x,  y,  2)  In  r(R,  0,  W (w),  zQ)  which  does  not 

satisfy  ss-property.  Suppose  t If  the  least  element  of  T such 
that  zt  does  not  satisfy  ss-property.  Since  zQ  satisfies 
ss-property,  t > 0.  By  choice  of  t,  zt-1  satisfies  ss-property 
and  zt  ^ f zt<  By  definition  of  i(R,  D,  W (w) , 2Q), 

(xt,  y^,  zt,  e W (w).  By  the  definition  of  W (w),  there  Is 

some  rule  pew  such  that  p(xt,  ) = (yt»  zt).  Since  zt  l 
satisfies  ss-property  and  p(xt,  2t_1)  = (yt»  z^)  and  p is 
ss-property-preservlng,  zt  satisfies  ss-property.  The  contradiction 
shows  that  l(R,  D,  W (w),  zq)  satisfies  ss-property. 

The  argument  Is  complete. 

theorem  A5:  Suppose  w is  a set  of  ‘-property  preserving  rules 

and  Zq  is  an  initial  state  which  satisfies  ‘-property.  Then 
e(R,  D,  w (w),  Zq)  satisfies  ‘-property. 

argument:  The  argument  is  that  of  theorem  A4  with  the  substitution 

of  ‘-property  for  ss-property. 

theorem  A6:  Suppose  w is  a set  of  ds-property  preserving  rules 

and  Zq  is  an  Initial  state  which  satisfies  ds-|  'operty.  Then 
e(R,  D,  W (w),  Zq)  satisfies  ds-property. 

corollary  A2:  Suppose  w is  a set  of  secure-state-preserving 

rules  and  Zq  is  an  Initial  state  which  is  a secure  state.  Then 
e(R,  D,  W (w),  Zq)  is  a secure  system. 

theorem  A7:  Suppose  v * (b,  M,  f,  H)  is  a state  which  satisfies 
ss-property,  (S,  0,  x)  i b,  b*  = b u {(S,  0,  x_)>,  and 
v*  = (b*.  M,  f,  H).  Then  v*  satisfies  ss-property  iff 
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(I)  (x  - e or  x - &)  or 

(II)  (x  « r or  x - w)  and  f$(S)  » fo(0). 

argument 

(-«>) 

Suppose  v*  - (b*.  M,  f,  H)  satisfies  ss-property.  Then 
0 e b*  (S:r,  w)-of$(S)  » fQ(0)  by  definition.  Therefore  (1)  or 
(11)  holds  since  x e {e,  w,  r,  a). 

( 0 ) 


Suppose  (1).  Then  v*  satisfies  ss-property  since  v does. 

Suppose  (11).  Then  for  any  S c S we  have 
0 E b*  (S:r,  w)"Ofs(S)  » fQ(0)  since  v satisfies  ss-property. 
Therefore  v*  satisfies  ss-property. 

theorem  A8:  Suppose  v - (b,  M,  f,  H)  Is  a state  which  satisfies 
♦-property  rel  S'cS,  SeS',  (S,  0,  x)  i b, 
b*  * b U((S,  0,  x)},  and  v*  - (b*,  M,  f,  H). 

v*  satisfies  *-property+  Iff 

(I)  If  x «•  a , then  fQ(0)  »fc(S); 

(II)  If  x » w , then  fc(S)  ■ fQ(S);  and 

(111)  If  x « r , then  fc(S)  » fo(0). 


t "rel  S'"  Is  understood. 
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argument: 


(->  ) Suppose  v*  satisfies  ‘-property.  The  definition  of  ‘-property 
applied  to  S,  0 and  (S,  0,  x)  yields  conditions  (1),  (11),  and 
(111)  directly. 

(o)  Suppose  conditions  (1)  - (111)  hold.  Let  (Sj,  Oj,  < b* 
with  S^  e S'.  If  (S^,  0j,  y)  e b,  the  ‘-property  conditions 
hold  for  f by  the  assumption  that  v satisfies  ‘-property.  If 
(S1.  °j*  Z)  4 b»  (S^.  0 j , y_)  - (S,  0,  x)  and  the  *•  propertj 
conditions  hold  by  the  Initial  assumption  of  conditions  (1)  • (111). 
Hence  v*  satisfies  ‘-property  as  desired. 

theorem  A9:  Suppose  v - (b,  K,  f,  H)  Is  a state  which  satisfies 

ds-property,  (S1 , 0H,  x)  t b,  b*  » b u((S.,  0<,  x)} , and 
v*  * (b‘,  M,  f,  H).  Then  v*  satisfies  ds-property  iff  x e 

argument: 

(-£>)  Suppose  v*  satisfies  ds-property.  Then  x.  e by 
definition. 

(-o  ) Suppose  x e f^j.  Then,  since  (Sr  0^,  x)  e b‘,  the 
proposition  ((Sj,  0j,  xj  e b*  »>  x.  e M^j)  Is  true;  therefore, 
v‘  satisfies  ds-property. 

corollary  A3:  Suppose  v * (b,  M,  f,  H)  is  a secure  state, 

(Si.  0j,  x)  i b,  b*  » b u {(Si,  0j,  x)}.  and  v*  - (b*,  M,  f,  H). 

Then  v*  Is  a secure  state  iff 

(1)  S..  e Sj  and  the  conditions  of  theorems  A7  and  A9 

are  met,  or 
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(11)  c S'  and  the  conditions  of  theorems  A7,  A*>#  and 
A9  are  met. 

theorem  A10:  Let  p be  a rule  and  p(Rk  ) ■ (Dm,  v*),  where 
v - (b,  M,  f,  H)  and  v*  - (b*.  fl*.  f*,  H*). 

(I)  If  b*Q  b and  f*  - f,  then  p Is  ss-property-preservlng. 

(II)  If  b*S  b and  f*  * f,  then  p Is  *-property- preserving. 

(Ill)  If  b*  C b and  M.jj*  5 for  all  1 and  j,  then  p 

Is  ds-property-preservlng. 

( 1 v)  If  b*  ^ b,  f*  « f,  and  M*j  2 for  all  1 and  j, 
then  p Is  secure-state-preserving. 


argument: 


(I)  If  v satisfies  the  ss  property,  then  (S,  0,  x)  e b* 
with  x « w or  r Implies  (S,  0,  x)  e b so  that 

f$  (S)  » f0  (0)  by  assumption.  Hence  f * (S)  » fQ*  (0) 
since  f*  ■ f.  Thus  v*  satisfies  ss-property  and  p 
Is  ss-property-preservlng. 

(II)  and  (111)  are  proved  In  ways  exactly  analogous  to 
the  proof  of  (i).  Implications  (1),  (11),  and 

(111)  prove  Implication  ( 1 v) . 
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Rules 

notation 


The  symbol  "v"  will  be  used  In  expressions  of  the  fomt  "A\B" 
to  mean  "proposition  A except  as  modified  by  proposition  B". 

Some  examples  follow.  Suppose  f is  a function  from  the  set 
(A,  B,  C}  to  the  set  {0,  1,  3}  defined  by: 

f (A)  - 1 or  (A,  1)  c f, 

f (B)  ■ 0 or  (B,  0)  e f, 

f(C)  '3  or  (C,  3)  c f. 

Then  fv.(C,  1)  or  f\f(C)  * 1 means 

f(A)  • 1. 

t(B)  ■ 0, 

f(C)  - 1. 

Suppose  M Is  a matrix.  Then  M\M, . «-  a "leans  the  matrix 

* J t h 

obtained  f.'om  M by  replacing  the  (1,  j)  element  by  a. 

MNM.  . u {x_}  means  the  matrix  obtained  from  M by  adding  the 
element  x to  the  (1,  j)  set  entry.  Similarly,  the  notation 
f\fQ  «-  fQ  u (°NEW(H)*  Lu>  Csee  Ru1e  nieans  the  function  obtained 
from  f by  replacing  f by  fQ  plus  the  ordered  pair 

^°NEW(H) * Lu^  ^fo  ^°NEW(H) ^ * Lu  ' The  notat1on  NEW(H)  denotes 
a selection  function  with  respect  to  the  hierarchy  H which 

specifies  an  arbitrary  Inactive  object  Index, 
def ini tlons  of  ru 1 e s 


The  definitions  of  Rules  1 to  11  are  given  In  the  following 
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pages.  These  rules  preserve  compatibility  and  assume  the  presence 
of  trusted  subjects. 
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Rule  5 ( R5 ) : release-read/execute/wri te/append 


Rule  7 (R7) : rescind- read/execute/xri te/append 


end; 


4i 


Rule  ?0  (RIO):  chanqe-subject-current-security-level 


Rule  11  { R1 1 ) : chanqe-ob ject-securi ty-level 


descriptions  of  rules 


rule  jj  get-read 

Request  Is  of  the  form  (g,  S } . 0^,  r). 
Subject  requests  access  to  object 


(r). 


in  read-only  mode 


If  request  Is  not  of  the  proper  form,  then  response  is  7^  with 
no  state  change. 

Otherwise,  the  following  conditions  are  checks. 1: 

( i ) Si  has  current  access  permission  to  0^  in 
read-only  mode. 

(ii)  the  security  level  of  dominates  the  security 
level  of  Oj. 

(iii)  is  a trusted  subject  or  the  current  security 
level  of  S.j  dominates  the  security  level  of  0j. 

If  conditions  (i)  - (ill)  are  met,  then  the  response  is  yes 
and  the  state  changes  by  adding  an  eni  > in  the  current  access  list 
indicating  that  S.  has  read-only  access  to  0^. 

Otherwise  the  response  is  rwwith  no  state  change. 
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rule  2:  get-append 


Pequest  Is  of  the  form  (g,  S^,  0^,  a). 

Subject  S1  requests  access  to  object  0j  in  append  mode  (a). 

If  request  is  not  of  he  proper  form,  then  response  is  7_ 
with  no  state  change. 

Otherwise  the  following  conditions  are  checked: 

(i)  has  « urrent  access  permission  to  0j  in 
append  mode. 

(11)  is  a trusted  subject  or  the  security  level 
of  0^  dominates  the  current  security  level  of 

S . . 

i 

If  conditions  (i)  - (ii)  are  mef,  ther,  the  response  is  yes  and 
the  state  changes  by  adding  an  entry  to  the  current  access  list 
indicating  that  S..  has  append  access  to  0^. 

Otherwise  the  response  is  no  with  no  state  change. 

rule  3:  get-execiu 

Request  is  of  the  form  (g,  Si , 0^,  e). 

Subject  S.  requests  access  to  object  0.  in  execute  mode 

* u 

(e). 
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If  request  Is  not  of  thi  p.opcr  form,  thei  the  response  is  ]_ 
with  no  state  change. 

Otherwise  the  following  condition  Is  checked: 

(1  has  current  access  permission  to  Oj  In  execute 
mode. 

If  condlt  on  (1)  Is  met,  then  the  response  Is  j£es_  and  the 
state  changes  by  adding  an  entry  to  the  current  access  list 
Indicating  that  has  execute  access  to  0 . 

Otherwise  the  response  Is  no  with  no  state  change. 
rule  4:  get-write 

Request  Is  of  the  form  (g,  , 0 j,  w). 

Subject  S.j  requests  access  to  object  0j  In  write  mode  (w). 

If  request  is  not  of  the  proper  form,  then  the  response  *s  T_ 
with  no  state  change. 

Otherwise  the  following  conditions  are  checked: 

(I)  S.j  has  current  access  permission  to  0j  In  write 
mode. 

(II)  the  security  level  of  dominates  the  security 
level  of  Oj. 
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(Ill)  Is  a trusted  subject  or  the  current  security 
level  of  Sj  equals  the  security  level  of  Oj. 

If  conditions  (1)  - (111)  are  met,  then  the  response  Is  yes 
and  the  state  changes  by  adding  an  entry  to  the  current  access  list 
Indicating  that  has  write  access  to  Oy 

Otherwise  the  response  Is  nt>  with  no  state  change. 


rule  5:  release-read/execute/wrlte/append 

Request  Is  of  the  form  (r,  S^,  Oj,  x). 

Subject  5^  signals  the  release  of  access  to  object  0,  In 

' J 

access  mode  x. 

If  request  Is  not  of  the  proper  form,  then  the  response  Is  ? 
with  no  state  change. 

Otherwise  the  response  is  yes^  and  the  state  changes  by 
removing  an  entry  from  the  current  access  list  Indicating  that 
no  longer  has  access  to  0.  in  mode  x. 

J 

rule  6:  gl ve-read/exccute/wrlte/append 

Request  is  of  the  form  (Sx,  g,  S^,  0 j , xj , 
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Subject  Sx  gives  to  subject  access  permission  to  Oj 
in  mode  x. 


If  request  Is  not  of  the  proper  form,  then  response  is  ^with 
no  state  change. 

Otherwise  the  following  condition  is  checked: 


(1)  object  Oj  is  not  the  root  object  of  the  hierarchy 
and  subject  Sx  has  current  access  in  write  mode  to 
Oj's  inwediately  superior  object  (0$  (j)}  in  the 
hierarchy 


or 

Oj  is  the  root  object  and  S^is  allowed  to  give 
access  permission  to  the  root  object  In  the 
current  state. 

If  condition  (1)  is  met,  then  the  response  is  yes  and  the 
state  Is  changed  by  adding  access  permission  for  to  Oj  In  mode 
x to  the  access  permission  matrix. 

Otherwise  the  response  is  no  with  no  state  change. 
rule  7:  rescind-rcad/evecute/wri te/append 

Request  is  of  the  form  (S^,  r,  S^,  Oj,  x). 

Subject  rescinds  subject  S^'s  access  permission  to  Oj 
in  mode  x. 
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If  request  Is  not  of  the  proper  form,  then  response  Is  ]_  with 
no  state  change. 

Otherwise  the  following  condition  Is  checked: 

(1)  object  Oj  Is  not  the  root  object  of  the 
hierarchy  and  subject  Sx  has  current  access 
In  write  mode  to  0^'s  Immediately  superior 
object  (0s(j))  the  hierarchy, 

or 

Oj  Is  not  the  root  object  and  Sx  Is  allowed  to 
rescind  access  permission  to  the  root  object  in  the 
current  state. 

If  condition  (1)  Is  met,  then  response  is  yes  and  the  state 
changes  as  follows: 

(I)  removal  of  an  entry  from  the  current  access  list 
Indicating  that  no  longer  has  access  to  Oj 
in  mode 

(II)  removal  of  access  pemv'ssion  for  to  Oj  in 
mode  x from  the  access  permission  matrix. 

Otherwise  the  response  Is  n£  with  no  state  change. 

rule  8:  create-object 

Request  is  of  the  form  (g,  , Oj,  Lu). 
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Subject  S..  generates  an  object.  requests  creation 
(i.e.,  attachment)  of  an  object,  denoted  having  security 

level  L^,  directly  below  object  0^  in  the  hierarchy 

H (0NEW(H)  E H(V'* 

If  request  is  not  of  the  proper  form,  then  response  is  ?_ with 
no  state  change. 

Otherwise  the  following  conditions  a^e  checked: 

(i)  S..  has  current  access  to  0^  in  write  or  append 

mode. 


(ii)  the  security  level  Lu  dominates  the  security  level 
of  0.. 

J 

If  conditions  (i)  - (ii)  are  met,  then  response  is  yes  and  the 
state  changes  as  follows: 


(i)  the  security  level  function  is  updated  by  adding  the 
ordered  pair  (0|^(h)»  tu)  (i.e.,  the  security  level 
of  is  rerorded  as  Lu). 


(ii)  the  object  0 
that  0NEW^Hj 


NEW(H)  is  added  to  the  hierarchy  such 
is  directly  below  °j ^°NEW(H ) e 


Otherwise  response  is  rm  with  no  state  change. 


rule  9:  delete-object-group 

Request  is  of  the  form  (S.,  0.). 

I J 
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Subject  S.|  requests  that  object  Oj  be  deleted  (detached  from 
the  hiera  rchy).  This  results  In  deletion  of  all  objects  in  the 
hierarchy  which  are  Inferion  to  (L. 

J 

If  request  is  not  of  the  proper  form,  then  response  is  £w1th 
no  state  change. 

Otherwise  the  following  condition  is  checked: 

(i)  S.  has  current  write  access  to  the  object 
immediately  superior  to  0^  (0S  (j)}  and  Oj 
is  not  the  root  object. 

If  condition  (i)  is  met,  then  response  is  yes.  and  the  state 
changes  as  follows: 

(i)  all  entries  In  the  current  access  list  giving  subjects 
access  to  0.  or  any  object  inferior  to  0.  in  any 

J J 

mode  are  removed  from  the  current  access  list. 

(ii)  all  entries  in  the  access  permission  matrix  giving 
subjects  access  permission  to  0-  or  any  object 

J 

inferior  to  0-  in  any  mode  are  removed  from  the 

J 

access  permission  matrix. 

(iii)  0-  and  all  objects  inferior  to  0.  are  removed 

J J 

from  the  hierarchy. 

Otherwise  response  is  no  with  no  state  change. 
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rule  10 


change-subject-current-security-level 


Request  Is  of  the  form  (S^,  Lu). 

Subject  requests  that  Its  current  security  level  be 
changed  to  Lu- 

If  request  Is  not  of  the  proper  form,  then  response  Is  ?_ with 
no  state  change. 

Otherwise  the  following  conditions  are  checked: 

(1)  S.j  is  a trusted  subject  or  if  S..  's  security  level 
were  changed  to  Lu,  then  the  resulting  state 
would  satisfy  *-property. 

(ii)  the  security  level  of  S..  dominates  Lu. 

If  conditions  (i)  - (ii)  are  met,  then  response  is  yes.  and  the 
state  changes  by  changing  the  current  security  level  of  S..  to  Lu. 

Otherwise  response  is  no  with  no  state  change. 
rule  11:  change-object-security-level 

Request  is  of  the  form  (r,  S^,  0^,  tu). 

Subject  requests  that  the  security  level  of  object  0j  be 
changed  to  Lu. 

If  request  is  not  of  the  proper  form,  then  response  is  T^with 
no  state  change. 
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Otherwise  the  following  conditions  are  checked: 


(i)  is  a trusted  subject  and  the  current  security  level 
of  dominates  the  security  level  of  Oj 

or 

the  current  security  level  of  dominates  l_u  and 

L dominates  the  security  level  of  0.. 
u J 

(11)  If  any  subject  S has  current  access  to  0.  in 
read  or  write  mode,  then  the  current  security  level 
of  S dominates  Lu> 

(ill)  If  Oj's  security  level  were  changed  to  Lu,  then 
the  resulting  state  would  satisfy  *-property. 

(iv)  if  0^'s  security  level  were  changed  to  Lu>  then 
compatibility  would  be  preserved  in  the  hierarchy. 

(v)  is  allowed  to  change  0 j 1 s security  level. 

If  conditions  (i)  - (v)  are  me*  then  response  is  yes_ and  the 
state  changes  by  changing  the  secu^  level  of  0^  to  Lu. 

Otherwise  response  Is  no^with  no  state  change. 

proofs 


rule  1 


Suppose  v satisfies  ss-property,  *-property  rel  S',  and 
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ds-property  and  Rfc  e R.  R1 (R^,  v)  * (Dm,  v*)  with: 

(I)  v*  » v or 

(II)  v*  - (b  U (Sr  Oj,  r),  M,  f,  H) 

If  (1),  then  v*  satisfies  ss-property,  *-property,  . d ds-property 
since  v does. 

Suppose  (11).  If  (S^,  Oj,  r)  e b,  then  v*  » v.  Suppose 
(Sr  Oj,  r)  i b.  Then,  since  f s ( S ^ ) » f 0 ( 0 j ) according  to  Rl,  v* 
satisfies  ss-property  by  theorem  A7  and,  since 
fc(Si)  » fo(0j)  If  Si  e S'  according  to  Rl,  v*  satisfies 
♦-property  rel  S'  by  theorem  A8  and,  since  re  according 

to  Rl,  v*  satisfies  ds-property  by  theorem  A9. 

Therefore  Rl  Is  secure-state-preserving  by  corollary  A3, 
rule  2 


Suppose  v satisfies  ss-property,  *-property  rel  S',  and 
ds-property  and  Rk  r R.  R2(Rk,  v)  » (Dm,  v*)  with 

(I)  v*  B v or 

(II)  v*  - (bu(Sr  Oj,  a),  M,  f.  H) 

Suppose  (11).  If  (S.j,  Oj,  a)  e b,  then  v*  ■ v.  Suppose 
(S.| , Oj,  a)  i b.  Then  v*  satisfies  ss-property  by  theorem  A7 
and,  since  fQ(0j)  xfc(Sj)  If  Sj  c S'  according  to  R2t<  v* 
satisfies  *-property  rel  S'  by  theorem  A8  and,  since  a_  e 
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according  to  R2,  v*  satisfies  ds-property  by  theorem  A9. 


Therefore  R2  is  secure-state-preserving  by  corollary  A3, 
rule  3 


Suppose  v Is  a secure  state  and  R^  e R. 

Suppose  v*  - (b  U (S,,  0.,  e),  M,  f,  H)  and  (S.,  0.,  a)  t b. 

* J ' J 

Then  v*  satisfies  ss-property  by  theorem  A7  and  v*  satisfies 
♦-property  rel  S'  by  theorem  A8  and,  since  £ e according  to 
R3,  v*  satisfies  ds-property  by  theorem  A9. 

Therefore  R3  is  secure-state-preserving  by  corollary  A3. 


rule  4 


Suppose  v is  a secure  state  and  e R. 

Suppose  v*  = (b  u (Sp  Oj,  w),  FI,  f,  H)  and  (S^ , 0j,  w)  i b. 

Then,  since  f s (S^ ) x fo(0j)  according  to  R4,  v*  satisfies  ss-property  by 

theorem  A7  and,  since  fc(S..)  = fQ(0j)  ^ Si  E s'»  v*  satisfies 
♦-property  rel  S’  ly  theorem  A8  and,  since  w e according  to 
R4,  v*  satisfies  ds-property  by  theorem  A9. 

Therefore  R4  is  secure-state-preserving  by  corollary  A3, 
rule  5 


Suppose  v is  a secure  state. 


124 


According  to  R5  b*  c b,  M*  ■ M»  and  f*  » f.  Therefore 
v*  Is  a secure  state  and  R5  Is  secure-state-preserving  by 
theorem  A10  (1v). 

rule  6 


Suppose  v Is  a secure  state. 

According  to  R6  b*«b  and  M*  B ^ u (x).  Therefor3  v*  Is 
a secure  state  and  R6  Is  secure-state-preserving  by  theorem  A10 
(1v). 

rule  7 


Suppose  v Is  a secure  state. 

According  to  R7  v*  = v or  v*  ■ (b  - (S..,  Oj,  x),  - (x) 

If  the  latter  then  It  Is  still  the  case  that  (S  , 0.  , x)  e b x e 

a b 

r.7  Is  ss-property-preservlng  and  ^-property-preserving  by  theorem 
A10  (1)  and  (1v).  Therefore  v*  Is  a secure  state  and  R7  is 
secure-state-preserving. 

rule  8 


Suppose  v is  a secure  state. 

According  to  R8  b*  = b and  M*  * M.  Since  (Sx,  ^ ^ 

for  any  S,  in  S and  x.  A,  v*  is  a secure  state  and  R8 
is  secure-state-preserving. 


f,  H). 
'ab* 
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rule  9 


Suppose  v Is  a secure  state. 

According  to  R9  If  (S  , 0 i,  x)  e b*t  then  x e M . so  v* 

a a — aa 

Is  a secure  state.  Therefore  R9  Is  secure-state-preserving, 
rule  10 


Suppose  v is  a secure  state. 

According  to  RIO  If  f*  r*  f then  f*  * f\f  (S.)<-  L and 

^ 1 U 

*10  (Rk,  v)  Is  true  so  v*  Is  a secure  slate.  Therefore  RIO  Is 
secure-state-preserving. 

rule  11 


Suppose  v Is  a secure  state. 

According  to  Rll  If  f*  f f then  f*  - f\fo(0j)f-  Ly  and 
*11  (R^.  v)  Is  true  so  v*  is  a secure  state.  Therefore  Rll  Is 
secure-state-preserving. 
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